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PREFACE 


This  database  specification  applies  specifically  to  HQ  USAFE  and  is  only  broadly 
applicable  to  the  other  MAJCOMs.  Each  MAJCOM's  requirements  will  be  thoroughly 
specified  during  the  in-depth  analysis  that  precedes  its  implementations. 


In  addition,  some  paragraphs  and  subtitles  have  been  added  to  or  deleted  from  the 
standards  specified  in  DoD  STD  7935.1,  24  April  1984,  as  a  result  of  their  applicability  to 
the  AFIRMS  database  located  at  the  HQ  USAFE  level. 
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SECTION  1.  GENERAL 


1.1  Purpose  of  the  HQ  USAFE  Database  Specification.  The  objectives  of  this  HQ  USAFE 
Database  Specification  for  the  Air  Force  Integrand  Readiness  Measurement  System 
(AFIRMS^^nder  Contract  No.  F49642-83-C-0022,  are  to  describe  the  storage  allocation 
and  database  organization  and  to  provide  the  basic  design  data  necessary  for  the 
construction  of  the  system  files,  tables,  dictionaries,  and  directories.  , 


r 

1.2  Project  References.  Accurate  assessment  of  force  readiness  and  sustainability  has 
been  a  constant  concern  of  Air  Force  commanders  and  their  staffs.  This  concern  has  been 
supported  by  an  intensified  DoD-wide  interest  in  capability.  In  response  to  this  Air  Force 
concern,  the  Directorate  of  Operations  and  Readiness  initiated  the  AFIRMS  Program. 
AFIRMS  has  been  under  development  through  a  learning  prototype  and  is  being  designed  to 
provide  Air  Force  commanders  with  a  complete,  timely,  and  accurate  assessment  of  their 
operational  readiness  and  sustainability.  ^  ■ 


The  Program  Management  Office  (PMO)  responsible  for  contract  management  of  the 
AFIRMS  Learning  Prototype  Phase  (LPP)  and  this  Database  Specification  is  the  Data 
Systems  Design  Office  (DSDO/XO),  Gunter  Air  Force  Station  (AFS),  Alabama;  the  Office 
of  Primary  Responsibility  (OPR),  is  the  United  States  Air  Force  Readiness  Assessment 
Group  (AF/XOOIM).  Three  operational  centers  have  been  in  use  as  LPP  testbed  sites: 

The  Pentagon,  Washington,  D.C.;  Headquarters  United  States  Air  Forces  Europe  (HQ 
USAFE),  Ramstein  Air  Base  (AB),  Germany;  and  the  52nd  Tactical  Fighter  Wing  (TFW), 
Spangdahlem  AB,  Germany. 


References  applicable  to  the  history  and  development  of  the  AFIRMS  Program  are 
listed  below,  along  with  references  concerning  documentation  and  programming  standards. 


Project  References 


a.  AFIRMS  Data  Requirements  Document,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

b.  AFIRMS  Economic  Analysis,  Final,  SofTech,  Contract  No.  F49642-83-C-0022, 
31  May  1985.  (Unclassified) 


c.  AFIRMS  Evolutionary  Implementation  Plan,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 


d. 

e. 

f. 

g- 

h. 

i. 

j- 

k. 

l. 

m. 

n. 

o. 

P- 

q- 

r. 

s. 

t. 

u. 


AFIRMS  Functional  Description,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

AFIRMS  HQ  USAF  Database  Specification,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

AFIRMS  HQ  USAF  Subsystem  Specification,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

AFIRMS  HQ  USAFE  Database  Specification,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

AFIRMS  HQ  USAFE  Subsystem  Specification,  Final,  SoiTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

AFIRMS  Product  Descriptions,  Final,  SofTech,  Contract  No.  F49642-83-C-0022, 
31  May  1985.  (Unclassified) 

AFIRMS  System  Specification,  Final,  SofTech,  Contract  No.  F49642-83-C-0022, 
31  May  1985.  (Unclassified) 

AFIRMS  Transform  and  Model  Descriptions,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

AFIRMS  Wing  Database  Specification,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

AFIRMS  Wing  Subsystem  Specification,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

System  Interface  Design  for  the  AFIRMS  LPP  and  the  Combat  Fuels 
Management  System  (CFMS),  SofTech,  Contract  No.  F49642-83-C-0022, 

28  February  1985.  (Unclassified) 

AFR  700-5,  Information  Systems  Requirements  Board,  9  November  1984. 
(Unclassified) 

System  Interface  Design  for  the  AFIRMS  LPP  and  the  Air  Force  Operations 
Resource  Management  System  (AFORMS),  SofTech,  Contract  No. 
F49642-83-C-0022,  2  November  1984.  (Unclassified) 

AFR  700-2,  Information  Systems  Planning,  26  October  1984.  (Unclassified) 

Automated  Data  Processing  (ADP)  Security  Policy,  Procedures,  and 
Responsibilities,  AFR  205-16,  1  August  1984.  (Unclassified) 

AFR  300-4,  Vol.  4,  Air  Force  Data  Dictionary,  1  May  1984.  (FOUO) 

Automated  Data  Systems  (ADS)  Documentation  Standards,  DoD-STD-7935. 1, 

24  April  1984.  (Unclassified) 

Department  of  Defense  Dictionary  of  Military  and  Associated  T^rms, 

3CS  Pub  1,  24  April  1984.  (Unclassified) 
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V.  AFR  700-1,  Managing  Air  Force  Information  Systems,  2  March  1984. 
(Unclassified) 

w.  AFIRMS  LPP  ADP  Security  Plan,  SofTech,  Contract  No.  F49642-83-C-0022, 

13  February  1985.  (FOUO) 

X.  AFR  300-4,  Vol.  3,  Air  Force  Data  Dictionary,  15  August  1983.  (FOUO) 

y.  Sustainability  Assessment  Model  (formerly  CAC)  Functional  Description, 
Contract  No.  F337'^0-83-G-002005701,  8  April  1983.  (Unclassified) 

z.  AFR  700-3,  Information  Systems  Requirements  Processing,  30  November  1984. 
(Unclassified) 


aa. 


ff. 
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MIL-STD-480  Configuration  Control-Engineering  Changes,  Deviations,  and 
Waivers. 


bb.  MlL-STD-483  Configuraton  Management  Practices  for  Systems,  Equipment, 
Munitions,  and  Computer  Programs. 


cc. 


USAF  Operational  Major  Command  Functional  Area  Requirement  (FAR), 
SofTech,  Contract  No.  F49642-82-C-0045,  15  December  1982.  (Unclassified) 


dd.  Unit  Combat  Readiness  Reporting  (C-Ratings)  (Unit  Status  and  Identity  Report 
(UNITREP),  RCS:HAF-XOO(AR)7112(DD)),  AFR  55-15,  22  November  1982. 
(Unclassified) 


ee.  USAFE  Annex  to  USAF  FAR,  SofTech,  Contract  No.  F49642-82-C-0045, 
20  August  1982.  (Unclassified) 


AFIRMS  FAR,  SofTech,  Contract  No.  MDA-903-76-C-0396,  14  March  1980. 
(Unclassified) 


gg* 

hh. 

ii. 

jj- 


AFIRMS  Data  Analysis,  SofTech,  15  February  1979.  (Unclassified) 

User's  View  of  AFIRMS,  SofTech,  1  November  1978.  (Unclassified) 

AFR  700-9,  Information  Systems  Standards,  15  March  1985.  (Unclassified) 


U.S.  Air  Force  Glossary  of  Standardized  Terms,  AFM  11-1,  Vol.  1,  2  January 
1976.  (Unclassified) 


kk.  AFIRMS  Data  Automation  Requirement  (DAR),  Final,  SofTech,  Contract  No. 
MDA-903-76-C-0396,  14  March  1980.  (Unclassified) 


11.  JCS  Memorandum  of  Policy  //172,  1  June  1982.  (Unclassified) 
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1.3  Terms  and  Abbreviations. 


1.3.1  Abbreviations  and  Acronyms. 


AAC 

AB 

A/C 

AD 

ADP 

ADS 

ADTAC 

AF 

AFB 

AFCC 

AFESC 

AFIRMS 

AFLC 

AFM 

AFMPC 

AFORMS 

AFOSP 

AFR 

AFRES 

AF5 

ALC 

ANG 

ARF 

ARMS 

ATC 

ATO 

A  TOC 

BLSS 

CAFMS 

CAl 

CAP  Report 
CAS 


Alaskan  Air  Command 
Air  Base 
Aircraft 
Air  Division 

Automated  Data  Processing 
Automated  Data  Systems 
Tactical  Air  Command  -  Air  Defense 
Air  Force 
Air  Force  Base 

Air  Force  Communications  Command 

Air  Force  Engineering  and  Services  Center 

Air  Force  Integrated  Readiness  Measurement  System 

Air  Force  Logistics  Command 

Air  Force  Manual 

Air  Force  Manpower  and  Personnel  Center 

Air  Force  Operations  Resource  Management  System 

Air  Force  Office  of  Security  Police 

Air  Force  Regulation 

Air  Force  Reserve 

Air  Force  Station 

Air  Logistics  Center 

Air  National  Guard 

Air  Reserve  Forces 

Ammunition  Reporting  Management  System  (D078) 
Air  Training  Command 
Air  Tasking  Order 

Allied  Tactical  Operations  Center  (NATO) 

Base  Level  Self-Sufficiency  Spares 
Computer  Aided  Force  Management  System 
Computer-Aided  Instruction 
Capability  Report 
Combat  Ammunition  System 
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CBPO 

- 

Consolidated  Base  Personnel  Office 

CFMS 

- 

Combat  Fuels  Management  System 

CINC 

- 

Commander  in  Chief 

COB 

- 

Collocated  Operating  Base 

COMPES 

- 

Contingency  Operations/Mobiiity  Planning  and  Execution  System 

COMSEC 

- 

Communications  Security 

CONUS 

- 

Continental  United  States 

CRT 

- 

Cathode  Ray  Tube 

CSC 

- 

Combat  Support  Group 

CSMS 

- 

Combat  Supplies  Management  System 

DAR 

- 

Data  Automation  Requirement 

DBMS 

- 

Database  Management  System 

DBS 

- 

Database  Specification 

DO 

- 

Deputy  Commander  for  Operations 

D078 

- 

ARMS  (Ammunition  Reporting  Management  System) 

DOC 

- 

Designed  Operational  Capability 

DoD 

- 

Department  of  Defense 

DRD 

- 

Data  Requirements  Document 

DSDO 

- 

Data  Systems  Design  Office 

EIP 

- 

Evolutionary  Implementation  Plan 

EMSEC 

- 

Emanations  Security 

FAR 

- 

Functional  Area  Requirement 

FD 

- 

Functional  Description 

FEO 

- 

For  Exposition  Only 

FMIS 

- 

Force  Management  Information  System 

FOCAS 

- 

Force  Capability  Assessment  System 

FORSCAP 

- 

Force  Capabilities  System 

FRAG 

- 

Fragmentary  Order 

GLCM 

- 

Ground  Launched  Cruise  Missile 

HOL 

- 

High  Order  Language 

HQ  USAF 

- 

Headquarters,  United  States  Air  Force 

HQ  USAFE 

- 

Headquarters,  United  States  Air  Forces  Europe 

HTACC 

- 

Hardened  Tactical  Air  Control  Center  (PACAF) 

IDS 

- 

Interface  Design  Specification 

IOC 

- 

Initial  Operational  Capability 

IG 

- 

Inspector  General 
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ICAM 

- 

Integrated  Computer-Aided  Manufacturing 

IDEF-1 

- 

ICAM  Definition  Method  One 

IRB 

- 

Is  Referenced  By 

JCS 

- 

Joint  Chiefs  of  Staff 

JCS  MOP  172 

- 

Joint  Chiefs  of  Staff  Memorandum  of  Policy  No.  172,  "Military 
Capability  Reporting,"  1  June  1982 

JOPES 

- 

Joint  Operations  Planning  and  Execution  System 

JOPS 

- 

Joint  Operations  Planning  System 

3RS 

- 

Joint  Reporting  System 

LAN 

- 

Local  Area  Network 

LCMS 

- 

Logistics  Capability  Measurement  System 

LIMFAC 

- 

Limiting  Factor 

LMC 

- 

Logistics  Management  Center 

LOGFAC 

- 

Logistics  Feasibility  Analysis  Capability 

LOGMOD 

- 

Logistics  Module 

LPP 

- 

Learning  Prototype  Phase 

MA 

- 

Deputy  Commander  for  Maintenance 

MAC 

- 

Military  Airlift  Command 

MAJCOM 

- 

Major  Command 

MDS 

- 

Mission  Design  Series 

MEI 

- 

Management  Effectiveness  Inspection 

MOB 

- 

Main  Operating  Base 

MTBF 

- 

Mean  Time  Between  Failure 

NAF 

- 

Numbered  Ai'"  Force 

NCO 

- 

Non-Commissioned  Officer 

OPlan 

- 

Operation  Plan 

OPR 

- 

Office  of  Primary  Responsibility 

OPSTAT 

- 

Operations  Status  Report 

ORI 

- 

Operational  Readiness  Inspection 

OSD 

- 

Office  of  the  Secretary  of  Defense 

OWRM 

- 

Other  War  Reserve  Materiel 

PACAF 

- 

Pacific  Air  Forces 

PCS 

- 

Permanent  Change  of  Station 

PMO 

- 

Program  Management  Office 

POE 

- 

Port  of  Embarkation 

POL 

- 

Petroleum,  Oil  and  Lubricants 

POM 

- 

Program  Objective  Memorandum 

POS 

- 

Peacetime  Operating  Stock 

RCS 

- 

Reports  Control  Symbol 

RM 

- 

Deputy  Commander  for  Resources 

SAC 

- 

Strategic  Air  Command 

SADT 

- 

Structured  Analysis  Design  Technique 

SAM 

- 

Sustainability  Assessment  Module  (Part  of  WSMIS  formerly  known  as 
CAC) 

SECDEF 

- 

Secretary  of  Defense 

SITREP 

- 

Situation  Report 

SQ 

- 

Squadron 

SOA 

- 

Separate  Operating  Agency 

SS 

- 

System  Specification 

TAC 

- 

Tactical  Air  Command 

TACNET 

- 

Tactical  Air  Command  Network 

TAP 

- 

Tactical  Air  Forces 

TBD 

- 

To  Be  Determined 

TPS 

- 

Tactical  Fighter  Squadron 

TPW 

- 

Tactical  Fighter  Wing 

UNITREP 

- 

Unit  Status  and  Identity  Report 

USAF 

- 

United  States  Air  Force 

USAFE 

- 

United  States  Air  Forces  Europe 

WIN 

- 

WWMCCS  Intercomputer  Network 

WIS 

- 

WWMCCS  Information  System 

WMP 

- 

War  Mobilization  Plan 

woe 

- 

Wing  Operations  Center 

WSAM 

- 

Weapon  System  Assessment  Model 

WSMIS 

- 

Weapon  System  Management  Information  System 

WWMCCS 

- 

World  Wide  Military  Command  and  Control  System 

1.3.2  Terms  and  Definitions. 


Autonomous 

Operation 


(CENTO,  NATO)  One  mode  of  operation  of  a  unit  in  which  the  unit 
commander  assumes  full  responsibility  for  control  of  weapons  and 
engagement  of  hostile  targets.  This  mode  may  be  either  directed  by 
higher  authority  or  result  from  a  loss  of  all  means  of 
communication.  (3CS  Pub  1) 
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Autonomous 

Operation 


Combat 

Capability 


Data 


Decision 

Deployment 

Employment 

Military 

Capability 


(DoD,  lADB)  In  air  defense,  the  mode  of  operation  assumed  by  a 
unit  after  it  has  lost  all  communications  with  higher  echelon.  The 
unit  commander  assumes  full  responsibility  for  control  of  weapons 
and  engagement  of  hostile  targets.  (JCS  ^b  1) 

The  readiness  status  of  a  unit  to  perform  its  tasked  combat  mission 
and  its  ability  to  sustain  a  required  level  of  tasking  for  a  specified 
number  of  days.  The  terms  "Combat  Capability"  and  "Readiness  and 
Sustainability"  are  used  interchangeably  throughout  the  AFIRMS 
documents. 

(DoD)  A  representation  of  facts,  concepts,  or  instructions  in  a 
formalized  manner  suitable  for  communication,  interpretation  or 
processing  by  humans  or  by  automatic  means.  Any  representation 
such  as  characters  or  analog  quantities  to  which  meaning  is  or  might 
be  assigned.  (3CS  Pub  1) 

(CENTO,  DoD,  lADB,  NATO)  In  an  estimate  of  the  situation,  a 
clear  and  concise  statement  of  the  line  of  action  intended  to  be 
followed  by  the  commander  as  the  one  most  favorable  to  the 
successful  accomplishment  of  his  mission.  (JCS  Pub  1) 

(CENTO,  DoD,  lADB,  NATO)  In  a  strategic  sense,  the  relocation  of 
forces  to  desired  areas  of  operation.  (3CS  Pub  1) 

The  tactical  usage  of  aircraft  in  a  desired  area  of  operation.  (AFM 
11-1) 

The  ability  to  achieve  a  specified  wartime  objective  (win  a  war  or 
battle,  destroy  a  target  set).  It  includes  four  major  components: 
force  structure,  modernization,  readiness,  and  sustainability.  (3CS 
MOP  172,  1  3une  1982) 

a.  Force  Structure  -  Numbers,  size,  and  composition  of  the  units 
that  comprise  our  defense  forces,  e.g.,  divisions,  ships,  airwings. 

b.  Modernization  -  Technical  sophistication  of  forces,  units,  weapon 
systems,  and  equipments. 

c.  Readiness  -  The  ability  of  forces,  units,  weapon  systems,  or 
equipments  to  deliver  the  outputs  for  which  they  were  designed 
(includes  the  ability  to  deploy  and  employ  without  unacceptable 
delays). 

d.  Sustainability  -  The  "staying  power"  of  our  forces,  units,  weapon 
systems,  and  equipments,  often  measured  in  numbers  of  days. 
(Note:  This  is  the  part  2.  definition  of  sustainability,  which  is 
published  alphabetically.) 

(CENTO,  NATO)  The  task  together  with  its  purpose,  thereby  clearly 
indicating  the  action  to  be  taken  and  the  reason  therefore.  The 
dispatching  of  one  or  more  aircraft  to  accomplish  one  particular 
task.  (3CS  Pub  1) 


Mission 


Shortfall 


The  absence  of  forces,  equipment,  personnel,  materiel,  or  capability 
—  identified  as  a  plan  requirement  --  that  would  adversely  affect 
the  command's  ability  to  accomplish  its  mission.  (Joint  Deployment 
Agency's  Joint  Deployment  System  Procedures  Manual,  1  January  82) 

Sortie  (air)  -  (CENTO,  NATO)  An  operational  flight  by  one  aircraft.  (JCS  Pub  1) 

Tasking  -  (NATO)  The  process  of  translating  the  allocation  into  orders,  and 

passing  these  orders  to  the  units  involved.  Each  order  normally 
contains  sufficient  detailed  instructions  to  enable  the  executing 
agency  to  accomplish  the  mission  successfully.  (JCS  Pub  1) 

Turnaround  -  (DoD,  lADB,  NATO)  The  length  of  time  between  arriving 

(Turn)  at  a  point  and  being  ready  to  depart  from  that  point.  It  is  used  in 

this  sense  for  the  loading,  unloading,  refueling  and  rearming,  where 
appropriate,  of  vehicles,  aircraft,  and  ships.  (JCS  Pub  1) 


1.4  Introduction  to  AFIRMS.  This  section  provides  a  brief  introduction  to  the  Air  Force 
Integrated  Readiness  Measurement  System  (AFIRMS).  A  more  complete  description  is 
provided  in  the  AFIRMS  Functional  Description. 


1.4.1  AFIRMS  Synopsis. 

1.4. 1.1  Key  AFIRMS  Concepts.  AFIRMS  is  an  automated,  tasking  based,  capability 
assessment  system.  As  such,  AFIRMS  evaluates  unit  and  force  capability  to  perform 
tasked  missions  based  on  the  availability  of  specific  resources. 


a.  The  conceptual  requirements  for  AFIRMS  are  two-fold; 

(1)  Assessment  of  combat  capability  against  specific  tasking.  The  user  can 
assess  unit/force  combat  capability  against  any  planned  or  ad  hoc  tasking, 
e.g..  War  Mobilization  Plan  (WMP),  Operation  Plan  (OPlan),  Fragmentary 
Order,  Air  Tasking  Order  (ATO),  Contingency  Plan,  etc. 

(2)  Assessment  of  combat  capability  based  on  budget  appropriations. 

AFIRMS  provides  a  tool  for  computing  long-term  readiness  and 
sustainability  trends,  spanning  two  to  six  fiscal  years.  This  tool  permits 
comparison  of  readiness  and  sustainability  by  fiscal  year  and  can 
therefore  highlight  the  impact  of  appropriation  changes.  Thus,  changes  in 
funding  are  related  to  changes  in  force  readiness  and  sustainability.  Also, 
senior  Air  Force  decision  makers  are  supported  during  budget 
deliberations  and  Air  Force  budget  allocations. 
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b.  AFIRMS  implementation  has  two  key  concepts: 

(1)  Integrated  approach  to  tasking  based  capability  assessments.  AFIRMS  has 
two  integrative  dimensions.  First,  all  applicable  resources  and  their  usage 
interactions  are  considered.  For  example,  in  sortie  capability  assessment, 
AFIRMS  evaluates  capability  in  terms  of  all  four  essential  resource  types 
(aircrew,  aircraft,  munitions,  fuel),  their  interdependencies,  and  their 
generative  components  (such  as  spares  for  aircraft,  training  qualifications 
for  aircrew,  load  crews  for  munitions,  and  hot  pits  for  fuel).  Second, 
other  automated  systems  (such  as  the  Combat  Supplies  Management 
System  (CSMS),  Combat  Fuels  Management  System  (CFMS),  Weapon 
System  Management  Information  System  (WSMIS),  etc.)  outputs  are 
integrated  into  capability  assessment  calculations  through  system 
interfaces  between  those  systems  and  AFIRMS. 

(2)  Data  Quality  Assurance.  Capability  assessment  is  no  better  than  the  data 
upon  which  it  is  based.  Therefore,  AFIRMS  emphasizes  a  user  orientation 
toward  quality  assurance  of  source  data.  Unit  and  other  data  input  level 
users  are  provided  effective  tools  to  accomplish  their  daily  activities  and 
therefore  develop  a  vested  interest  in  AFIRMS  data  currency  and 
validity.  Capability  assessment  data  can  then  be  extracted  for  use  by 
higher  or  parallel  users  with  maximum  confidence  in  its  validity. 


1.4. 1.2  AFIRMS  Functions.  Four  basic  AFIRMS  functions  combine  to  assess  readiness 
capability: 


a.  Translate  Tasking.  As  a  tasking  based  capability  assessment  system,  tasking 
must  be  converted  into  a  standard  format  recognized  by  AFIRMS.  Tasking  is 
defined  in  AFIRMS  to  the  unit  level  and  may  consist  of  actual,  hypothetical, 
standard,  or  contingency  tasking.  Any  of  these  taskings  can  be  defined  within 
specified  WMF  or  OPlan  constraints,  at  the  option  of  the  user.  Likewise,  the 
tasking  may  be  defined  by  the  user  for  present,  historic  or  future  requirements. 

b.  Define  Resources.  The  resource  definition  function  of  AFIRMS  ensures  that 
information  about  inventory  status  is  available  and  accurate.  Wherever 
possible,  this  data  is  obtained  by  interface  with  other  functional  systems.  As 
with  tasking,  resource  information  can  be  defined  for  actual,  hypothetical, 
standard,  or  contingency  situations,  either  present,  historic,  or  future. 

c.  Determine  Ability  to  Perform.  Determining  the  force's  ability  to  perform  is 
the  essential  function  of  AFIRMS.  The  tasking  and  resource  data  are  processed 
to  determine  how  much  of  the  specified  tasking  can  be  accomplished  with  the 
resources  available.  Ability  to  perform  is  evaluated  in  terms  of  the  task  metric 
(sorties,  etc.)  and  the  cost  metric  (dollars)  to  provide  readiness/sustainability 
and  dollars  to  readiness  assessments. 

d.  Aggregate,  Analyze  and  Present  Data.  Aggregation,  analysis  and  presentation 
ensure  the  proper  grouping  and  display  of  data  to  provide  useful  information  at 
the  unit,  major  command  and  HQ  USAF.  Aggregation  refers  to  the  creation  of 
a  composite  understanding  of  capability  for  several  units. 


1.4.2  AFIRMS  Documentation .  A  set  of  nine  types  of  documents  describes 
AFIRMS.  A  list  of  these  AFIRMS  documents  is  provided  below  along  with  a  short 
description  of  the  particular  aspects  of  AFIRMS  which  are  addressed  by  each 
document. 


a.  Functional  Description  (FD) .  The  FD  provides  the  description  of 
AFIRMS  concepts  in  user  terms.  It  is  the  baseline  document  which 
ties  the  AFIRMS  documents  together. 

b.  Economic  Analysis  (EA).  The  EA  states  AFIRMS  estimated  costs.  It 
explains  the  cost  factors  of  AFIRMS  implementation  alternatives  and 
states  the  recommended  alternative. 

c.  Management  Plan.  The  Management  Plan  provides  the  top-level, 
integrative  frame  of  reference  for  the  AFIRMS  Program.  The  plan 
focuses  on  the  processes  which  provide  technical  and  administrative 
control  of  AFIRMS .  Key  annexes  to  the  Management  Plan  are  the 
Evolutionary  Implementation  Plan,  the  Configuration  Management 
Support  Plan,  and  the  Systems  Interface  Support  Plan. 

d.  System  Specification.  The  AFIRMS  System  Specification  adds  the 
design  requirements  to  the  functional  concepts  in  the  FD.  It  divides 
the  system  into  subsystems  (HQ  USAF,  HQ  USAFE  (MAJCOM),  and  Wing 
(unit))  and  assigns  functions  required  within  each  subsystem.  The 
system  specification  details  the  overall  architecture,  intersite 
interface  gateways,  processing  logic  flows  and  the  communications 
network  specifications. 

e.  Subsystem  Specifications.  There  are  three  AFIRMS  subsystem 
specifications:  HQ  USAF,  HQ  USAFE  (MAJCOM/numbered  Air  Force),  and 
the  Wing  (unit/squadron).  Subsystem  specifications  detail  the 

specific  design  and/or  performance  requirements  of  the  system  at  that 
level.  Design  details  cover  the  architecture,  required  functions, 
the  functioned  users,  intrasite  interface  gateways,  and  applicable 
processing  logic  flows. 

f.  Database  Specifications.  There  are  three  AFIRMS  database 
specifications:  HQ  USAF,  HQ  USAFE  (MAJCOM/numbered  Air  Force),  and 
Wing  (unit/squadron).  These  specifications  describe  the  database 
architecture,  size  and  content,  as  well  as  logical  data  relationships 

for  the  functions  performed  at  each  of  the  AFIRMS  levels. 

g.  Data  Requirements  Document  (DRD).  The  DRD  identifies,  categorizes, 
and  groups  the  generic  types  of  data  used  in  AFIRMS.  It  also  defines 
each  type  of  AFIRMS  data  element  (attribute  class). 

h.  Product  Descriptions  (PDs).  The  PDs  visually  portray  the  products 
which  implement  the  AFIRMS  functions  as  input  and  output  tools. 
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Transform  and  Model  Descriptions.  The  Transform  and  Model 
Descriptions  Document  defines  how  AFIRMS  calculates  the  output  data 
from  the  input  data.  Specific  algorithmic  calculations  are  provided. 
Logical  groups  of  algorithms  forming  AFIRMS  models  and  trauisforms  are 
described. 


SECTION  2.  DATABASE  IDENTIFICATION  AND  DESCRIPTION 


This  section  discusses  the  information  necessary  for  identifying  and  describing  the  HQ 
USAFE  level  subsystem  database.  It  also  contains  information  on  the  recommended 
organization  of  the  HQ  USAFE  database  which  is  essential  for  proper  utilization  of  the 
database.  This  section  is  intended  primarily  to  acquaint  the  AFIRMS  database  designer 
with  the  overall  issues  concerning  data  redundancy  between  and  within  sites,  speed,  and 
software  development  required  to  manage  AFIRMS  data. 


2.1  Database  Identification.  The  label  by  which  the  HQ  USAFE  level  database  is  uniquely 
identified  will  include  the  site  identification  and  ”DB'’  as  a  suffix  (e.g.,  HQUSAFEDB). 


2.1.1  System  Using  the  Database.  The  system,  of  which  the  HQ  USAi  E  level  database  is 
part,  is  the  Air  Force  Integrated  Readiness  Measurement  System  (AFIRMS). 


2.1.2  Storage  Requirements.  A  method  for  estimating  the  database  storage  requirements 
for  the  MA3CQM  level  site  of  AFIRMS  is  discussed  in  this  section. 

An  example  is  shown  below  of  information  that  is  collected  for  each  Appearance 
Class  listed  in  the  DRD,  stored  at  the  MAJCOM,  and  used  to  calculate  an  appropriate 
sizing  estimate.  This  example  is  an  excerpt  from  the  list  given  in  Appendix  A  for  the 
central  site  database. 


APPEARANCE 

NUMBER 

APPEARANCE  NAME 

SIZE 

QUANTITY 

TOTAL 

SIZE 

96C 

RESOURCE  STATUS 

3 

3120 

56160 

53F 

BASE  ETIC 

11 

100 

6600 

From  left  to  right  are  listed  the  appearance  number  of  each  item  in  question,  its 
name,  and  other  information  pertaining  to  its  storage  in  the  central  database.  Some 
appearance  class  names  have  a  brief  description  included  to  identify  the  assumptions 
behind  the  quantity. 
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The  Resource  Status  describes  the  status  of  an  individual  resource,  e.g.,  3P-4.  The  next 
column,  size,  indicates  maximum  length  in  bytes  of  the  appearance.  For  alpha  or 
alphanumeric  data  types,  size  equals  the  maximum  length  possible  for  that  appearance. 
Use  of  the  maximum  length  results  in  worst-case  database  sizing  estimates.  An 
alternative  method  of  estimating  size  employs  an  average  length  of  AFIRMS  character 
data.  Another  approach  is  to  assume  that  all  character  data  is  stored  witn  the  use  of  a 
compression  algorithm.  These  alternatives  are  evaluated  during  the  Analysis  Phase  of  the 
initial  block  of  each  segment  before  the  final  database  sizing  estimate  is  given.  In  the 
case  of  numeric  data,  i.e.,  real  or  integer  values,  size  is  set  equal  to  4  bytes.  Quantity, 
the  next  column,  indicates  how  many  instances  of  the  appearance  exist  in  the  site's 
central  database. 

In  the  sample  table  above,  if  there  were  80  wings  and  39  resources  for  each  wing  are 
to  be  monitored  and  stored  in  the  site's  central  database,  then  the  Resource  Status  is 
stored  3120  times  to  accomodate  all  80  wings.  Similarly,  if  there  were  100  bases,  each 
needing  monitoring  by  HQ  USAFE,  100  Base  ETICS  would  be  stored.  The  final  column, 
total  space,  reflects  the  total  space  necessary  to  store  that  appearance  class  in  the  site's 
central  database.  This  figure  is  derived  from  the  maximum  length  multiplied  by  the 
quantity  and  this  result  then  multiplied  by  a  factor  of  6.  The  multiplication  factor  of  6 
represents  the  actual  storage  for  the  appearance  plus  storage  space  for  a  combination  of  3 
historical  or  "what-if"  copies  of  the  appearance.  The  sum  of  the  total  space  needed  over 
the  entire  Appendix  A  listing  yields  total  space  required  for  the  central  database.  Note 
that  the  totals  are  for  HQ  USAFE  and  reflect  Fighter/Reconnaissance  needs.  Other 
MAJCOMs  use  fewer  resources  and  therefore,  have  smaller  total  sizing  estimates. 

In  Appendix  B,  the  sizing  process  is  accomplished  for  each  HQ  USAFE  functional  area 
participating  in  AFIRMS.  Note  that  the  estimates  in  Appendix  B  must  be  refined 
depending  on  the  degree  of  data  redundancy  required  by  the  data  management  software 
selected  for  implementation.  Both  software  selection  and  final  sizing  occur  during  the 
analysis  phase  of  the  initial  block  of  each  segment.Table  2-1  contains  the  factors  actually 
used  to  compute  the  database  sizings  for  an  operational  AFIRMS  at  HQ  USAFE. 
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Table  2-1 

HQ  USAFE  OPERATIONAL  DATABASE  SIZING  FACTORS 


LEGEND: 


Col- 1  represents  the  total  number  of  screens  used  by  a  specific  functional  area  during  the 
LPP. 

Col-2  represents  the  total  number  of  new  screens  used  by  a  specific  functional  area  during 
operational  AFIRMS. 

Col-3  represents  the  percentage  increase  of  new  screens  over  those  used  during  the  LPP 
(i.e.,  Col-2  divided  by  Col-1  times  100). 

Col-4  represents  the  original  database  size  (as  a  percentage)  plus  the  percentage  increase 
of  the  database  size  due  to  the  new  operational  screens.  It  is  assumed  that  all  new 
screens  will  use  25%  of  the  data  already  existing  in  the  database.  The  remaining  75% 
of  data  used  by  the  new  screens  is  estimated  to  be  new.  Note  that  the  75%  new  data 
must  be  applied  to  the  percentage  of  new  screens  (Col-3)  to  obtain  the  actual 
percentage  increase  in  size  of  the  database  (i.e.,  multiply  CoI-3  by  0.75  by  100). 

Col-5  represents  the  percentage  increase  in  size  of  the  database  when  the  five  additional 
factors  shown  below  are  accounted  for  in  addition  to  Col-4: 
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a.  0.75  - 

b.  1.01  - 

c.  1.01  - 

d.  1.65  - 

e.  1.50  - 


compression/encoding, 

time  stamping  at  the  record  level, 

editing/validition  data, 

typical  DBMS  miscellaneous  data  overhead  requirement, 

key  propagation  required  for  a  relational  DBMS  implementation. 


The  first  factor  tends  to  decrease  database  size;  though  the  others  all  increase 
database  size.  When  these  factors  are  multiplied  together,  a  combined  factor  of  1.89 
is  generated.  That  is  an  89%  increase  in  database  size.  To  determine  the  actual 
percentage  increase,  we  must  multiply  Col-4  by  1.89  by  100.  This  percentage 
increase  is  applied  to  all  database  size  estimates  mentioned  on  subsequent  pages  to 
determine  the  estimated  operational  database  size  for  each  functional  area  and  the 
central  database. 
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The  database  sizing  estimates  presented  in  the  appendices  are  based  on  the 
assumption  that  the  MAJCOM's  Fighter/Reconnaissance  resources  are  augmented  during 
crises  situations  by  numerous  CONUS  units.  As  a  result,  the  database  sizing  estimates 
were  increased  for  the  worst-case  scenario. 

The  wing  database  sizing  requirements  should  also  be  increased  based  on  this 
assumption.  The  basic  question  is  "How  much  should  the  wing  database  sizing  be 
increased?"  While  the  worst-case  sizing  estimates  for  HQ  USAFE  are  determinable  and 
justifiable  without  specific  wing  bed-down  plans,  any  wing  database  sizing  which  does  not 
consider  worst-case  scenario  is  invalid. 

It  is  reasonable  to  assume  that,  during  crises,  what-if  versions  of  the  central  and 
functional  area  databases  au‘e  off-loaded  to  provide  sufficient  space  to  accommodate 
augmentation.  However,  the  best  solution  is  to  first  determine  the  worst-case 
augmentation  plan,  and  subsequently  use  that  plan  to  determine  the  actual  database  size 
for'various  wings  in  the  MAJCOM.  This  requirements  analysis  and  sizing  determination  is 
an  integral  part  of  the  Analysis  Phase  of  initial  blocks  for  each  segment. 

Note  that  the  estimates  in  the  Appendices  for  units  and  bases  do  not  necessarily 
represent  physical  units  and  basev  They  represent  the  need  to  maintaun  data  about  these 
entities  and  account  for  the  possibility  that  a  unit  may  deploy  to  many  different  types  of 
bases,  e.g..  Collocated  Operating  Bases,  Forward  Operating  Locations,  Aerial  Ports  of 
Debarkation,  etc. 

Each  AFIRM5  site  has  a  parameter  accessible  by  a  system  manager  that  controls  the 
number  of  copies  of  what-if  databases  by  functional  area.  As  use  of  the  system  increases, 
this  parameter  can  be  used  as  a  tuning  mechanism  to  increase  or  decrease  the  number  of 
on-line  copies  of  what-if  databases  by  functional  area  in  order  to  manage  available  disk 
space.  The  value  of  this  parameter  is  set  to  five  for  the  database  sizing  estimates  of  this 
document. 

The  growth  rate  of  the  MAJCOM  database  is  estimated  as  approximately  10%  per 
year.  The  capability  for  on-line  storage  of  one  copy  of  real  data  plus  five  copies  of 
what-if  data  is  required  at  the  HQ  USAFE  level  to  accommodate  readiness  assessment  and 
dollars  to  readiness  evaluations.  Copies  of  data  in  excess  of  the  five  on-line  at  any  one 
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time  are  maintained  off-line.  The  five  copies  maintained  on-line  support  the  following 
estimated  requirements  for  copies  of  data: 

Exercises  (1  beginning  copy,  1  end  copy) 

Ad-hoc  what-ifs  (5  copies) 

OPLAN  what-ifs  (36  copies  =  12  plans  x  3  copies) 

POM  what-ifs  (6  copies). 

Copies  of  what-if  data  in  excess  of  the  five  permitted  on-line  at  any  one  time  are 
maintained  off-line. 

Sizing  estimates  comform  to  the  assumption  that  the  AFIRMS  database  architecture 
at  the  MA3COM  level  is  one  of  attribute  segmentation.  In  this  architecture,  each 
functional  area  is  responsible  for  its  own  data.  A  copy  of  all  functional  area  data  resides 
in  a  centralized  database,  duplicating  data  for  the  functional  areas.  Data  attributes  that 
are  normally  used  by  a  given  functional  area  reside  at  that  functional  area  with  updates 
transmitted  to  and  from  the  central  database.  If  data  that  is  not  resident  at  a  given 
functional  area  is  required  at  that  functional  area,  then  that  data  is  downloaded  to  that 
location  along  with  software  needed  to  access  it.  The  degree  of  redundancy  necessary 
must  be  determined  before  final  sizing  estimation.  Following  the  determination  of  a 
functional  area's  sizing  estimate,  the  number  of  what-if  databases  to  be  maintained 
on-line  is  specified.  Finally,  the  actual  data  and  its  redundancy  within  a  site  for  real  and 
what-if  purposes  is  determined.  These  issues  are  addressed  by  the  database  designer  in 
the  Analysis  Phase  of  the  initial  block  of  each  segment  for  accurate  sizing  estimates. 
Estimates  given  in  Appendices  A  and  B  are  provided  for  planning  purposes. 

Until  the  actual  DBMS  Is  chosen,  the  estimates  shown  in  Appendices  A  and  B,  with 
some  refinement,  suffice  as  a  starting  point  for  most  economic  considerations  as  well  as 
high-level  design  decisions.  The  estimates  can  also  be  used  as  a  tool  in  the  comparison  of 
different  DBMSs.  When  an  actual  DBMS  is  chosen,  those  factors  indigenous  to  the  data 
model  and  the  DBMS  are  used  for  calculating  a  more  refined  space  requirement  estimate. 
After  final  data  requirements  are  determined  during  the  Analysis  Phase  of  each  segment, 
sizing  requirements  will  probably  be  lower  for  the  functional  areas  than  estimated  in 
Appendix  B. 
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2.1.3  Physical  Description  of  the  Database  Files.  The  master  file(s)  containing  the  HQ 
USAFE  level  database  are  stored  on-line  on  non-volatile  random  access  mass-storage 
media  with  back-ups  off-line  on  magnetic  tape  or  floppy  disk. 

2.2  Organization  of  the  Database.  There  are  many  differences  between  a  database  design 
in  the  classical  sense,  where  a  DBMS  is  chosen  and  a  schema  (or  logical  design)  is 
developed,  and  the  design  of  the  AFIRMS  databases.  AFIRMS  can  accommodate  many 
different  DBMSs  and  schemas.  Complexities  arise  because  AFIRMS  resides  at  three 
different  levels  of  the  command  structure.  Standard  database  issues  such  as  security,  ad 
hoc  query  capability,  and  data  communications  become  very  complicated  when  the  ability 
to  receive  and  transmit  data  between  sites  is  considered  the  basis  of  the  system.  During 
the  Analysis  Phase  of  the  initial  block  of  each  segment,  the  database  designer  must  be 
aware  of  these  problems  and  realize  that  the  design  of  the  database  at  each  level  is  highly 
dependent  upon  the  other  levels. 

The  design  of  the  AFIRMS  database  will  support  the  requirements  for  an  interactive 
query  capability  accessing  current,  historical,  and  hypothetical  (what-if)  data.  Historical 
data  resides  on  off-line  media  and  is  copied  to  on-line  media  on  an  "as-needed"  basis.  In 
order  to  accommodate  this  and  to  minimize  the  amount  of  time  necessary  to  develop 
applications,  a  commercial  DBMS  software  package  i.e.,  "off  the  shelf,"  is  utilized.  It 
should  also  be  noted  that  not  all  MAJCOM  data  management  requirements  can  be  met  by 
a  single  DBMS.  A  DBMS  may  be  resident  at  the  central  location  of  each  MAJCOM  along 
with  any  other  software  necessary  to  manage  the  data  at  the  functional  areas.  The 
database  that  the  DBMS  operates  upon  resides  primarily  on  non-volatile  random  access 
media  with  backups  and  copies  residing  on  non-volatile  media. 

The  data  model(s)  used  in  a  particular  segment  is  determined  during  the  Analysis 
Phase  of  the  initial  block  of  each  segment.  As  a  result,  the  DBMS  used  for  the  central 
database  and  the  data  management  software  at  each  functional  area  are  unknown,  as  is 
the  actual  physical  structure  of  that  data  as  it  will  exist  on  disk  and  tape  media. 

There  are  two(2)  basic  requirements  of  AFIRMS  at  the  MAJCOM  level  that  relate  to 
the  choice  of  a  DBMS  and  the  design  of  the  database.  They  are  reliability /availability, 
and  reportability. 
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The  basic  long-term  requirements  include: 

a.  Reliability/Availability.  Reliability/Availability  is  the  ability  of  the  system  to 
be  accessible  to  all  users  and  the  requirement  for  the  accuracy  of  AFIRMS  data 
to  be  very  high  during  peacetime  and  crises.  Survivability  during  wartime  is  not 
presently  a  requirement  for  operational  AFIRMS. 

b.  Reportability.  Reportability  is  the  ability  of  a  unit  or  functional  area  to  report 
its  status  upward  to  the  parent  unit  regardless  of  its  current  location.  When  the 
reporting  unit  is  able  to  connect  to  an  operating  AFIRMS  not  within  its  parent 
wing  or  MA3COM,  AFIRMS  provides  the  capability  to  transmit  status  of  the 
reporting  unit  to  the  parent  database. 

2.2.1  Database  Architecture  Options.  In  order  to  arrive  at  an  acceptable  database 
architecture  to  support  AFIRMS  at  HQ  USAFE,  a  number  of  feasible  database 
architectures  were  evaluated  in  terms  of  the  requirements  outlined  in  the  previous  section 
as  well  as  hardware  and  software  development  costs,  performance,  and  maintainability. 
These  alternatives  were  also  evaluated  in  terms  of  system  expandability  without 
modification  to  the  data  structure  and  software. 

The  AFIRMS  database  architecture  supporting  HQ  USAFE  is  designed  to  operate  in 
normal  peacetime  conditions  and  crises.  Two  conceptual  database  architectures  that 
were  evaluated  include  data  centralization  (2.2. 1.1  below)  and  data  distribution  (2.2. 1.2). 

A  brief  explanation  of  each  of  these  is  provided  in  the  following  sections.  These 
explanations  are  intended  to  give  a  summary  of  the  conceptual  database  architectures, 
but  are  not  intended  to  imply  that  a  copy  of  a  DBMS  should  reside  at  each  functional 
area.  Nor  do  they  imply  that  any  particular  data  management  or  file  system  should  be 
employed  to  manage  the  data  at  each  functional  area.  The  primary  requirement  is  that  if 
data  is  required  to  be  resident  at  a  functional  area,  software  must  also  be  present  to 
handle  it,  and  to  manage/control  concurrency  problems  that  occur. 

In  general,  the  operating  costs  of  a  database  consist  of  storage  costs  of  file  copies 
and  communications  costs  for  queries  and  updates.  High  redundancy  tends  to  decrease 
communications  costs  for  queries  because  data  is  local  to  the  user.  However,  high 
redundancy  increases  storage  and  communications  costs  for  updates  because  many  files 
are  affected  by  the  update  of  one  version.  Low  redundancy  has  the  opposite  tendency. 
Cost/benefit  analysis  using  high  and  low  redundancy  is  of  major  importance  in  the 
database  architecture  selection  process. 


2.2. 1.1  Data  Centralization.  Total  centralization  of  data  was  the  database  architecture 
employed  in  the  AFIRMS  LPP  for  the  prototype  databases.  All  of  the  data  used  by  the 
system  resides  on  a  central  computer  under  the  management  of  a  single  DBMS.  Some 
transactions  that  occur  have  proven  to  be  quite  burdensome  on  the  central  computer.  The 
degree  to  which  the  Central  Processing  Unit  (CPU)  is  dominated  by  the  DBMS  is  termed 
CPU-boundedness  and  can  be  tuned  more  or  less  with  DBMS  system  parameters.  However, 
LPP  applications  software  resident  on  the  central  computer  was  also  highly  CPU-bound. 

This  caused  competition  for  CPU-time  when  more  than  one  transaction  was  executed  at  a 
time  and  the  DBMS  CPU  demands  compounded  the  problem.  The  DBMS  can  be  adjusted  to 
lower  its  demand  for  CPU  but  the  cost  is  an  increase  in  its  need  for  input/output.  Thus  a 
CPU  bottleneck  becomes  an  input/output  bottleneck.  The  result  is  that  the  transactions 
become  queued  waiting  for  disk  access. 

In  a  centralized  processing  environment,  CPU-boundedness  is  to  be  expected.  In  this 
situation,  the  most  straightforward  solution  is  a  larger  and  faster  computer.  However,  this 
is  relatively  expensive  in  light  of  the  many  sites  AFIRMS  intends  to  support.  I/O-bound 
processing  is  likely  to  occur  with  architectures  using  a  back-end  database  machine  because 
processes  in  the  main  computer  would  become  queued  while  others  finish  in  the  database 
processor. 

A  centralized  database  at  the  HQ  USAFE  level  is  a  very  vulnerable  system  in  the  event 
of  hardware  failure  bacause  of  their  single  location.  AFIRMS  is  unavailable  during  such 
failures.  Reportability  also  suffers  when  the  central  database  is  unavailable.  Conversely, 
software  development  and  maintenance  costs  are  usually  at  their  lowest  with  this 
architecture  because  all  of  the  software  and  data  reside  at  a  single  location.  High-powered 
hardware  would  be  required  at  the  central  location,  but  dumb  terminals  would  suffice  for 
support  of  the  functional  areas. 

2.2. 1.2  Data  Distribution.  Five  variations  of  data  distribution  were  evaluated:  full 
redundancy  (2.2. 1.2.1  -  below),  entity  redundancy  (2.2. 1.2.2),  attribute  segmentation 
(2.2. 1.2.3),  record  or  tuple  segmentation  (2. 2.1. 2.4),  and  record/attribute  segmentation 
(2.2. 1.2.5).  Conceptually,  each  variation  could  be  implemented  with  or  without  a  redundant 
master  copy  of  data  residing  at  a  central  location.  This  master  copy  is  the  equivalent  of  the 
union  of  all  the  functional  areas'  databases.  A  distributed  data  implementation  without  the 
inclusion  of  a  master  copy  was  deemed  too  costly  and  unreliable.  Another  disadvantage  is 
that  there  are  currently  no  distributed  DBMSs  available  commercially. 
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Each  variation  discussed  is  based  on  the  assumption  that  there  is  a  central  database  at 
HQ  USAFE  with  a  varying  degree  of  data  redundancy  at  the  functional  areas.  A  common 
thread  exists  among  the  variations.  Updates  to  data  are  made  at  a  functional  area, 
transmitted  to  the  central  database,  and  subsequently  transmitted  to  all  affected  functional 
areas  where  final  updates  occur.  After  each  variation  is  evaluated  relative  to  the  others,  a 
conclusion  is  reached  concerning  its  feasibiltiy  for  operational  AFIRMS. 

Certain  advantages  are  inherent  to  an  architecture  with  a  centralized  database.  A  degree 
of  interface  control  is  available  in  that  both  magnetic  tape  and  direct-line  interfaces  to  other 
systems  can  occur  at  the  central  location  and  data  can  then  be  downloaded  to  the  appropriate 
functional  area(s).  The  same  advantage  works  for  systems  desiring  access  to  AFIRMS  data. 
Also,  periodic  database  backups  occur  more  cleanly  and  with  minimal  impact  on  the  system. 
Again,  if  the  central  location  is  incapacitated,  these  capabilities  may  be  hindered  if  not 
eliminated.  However,  the  inherent  contingency  capability  provided  by  this  architecture 
provides  for  standalone  AFIRMS  operations  in  the  functional  areas  as  a  minimum. 

Reportability  is  accomplished  relatively  easily  if  the  central  location  is  operating,  and 
less  smoothly  from  a  functional  area  when  it  is  down. 

Although  a  data  distribution  architecture  with  a  central  database  does  combine  some  of 
the  advantages  of  the  distributed  and  centralized  concepts,  there  are  also  some  disadvantages 
to  the  data  distribution  architecture.  Specifically,  more  intelligent  software  is  required  to 
manage  the  distributed  data.  A  disadvantage  of  total  data  centralization  also  present  with 
this  architecture  is  the  centralization  of  both  communications  and  data.  Since  all  site  data 
communications  must  be  routed  through  the  central  database,  AFIRMS  is  only  as  reliable  as 
the  central  location  of  its  database. 

In  the  event  that  the  central  location  goes  down,  the  functional  areas  cannot  receive 
data  updates  from  other  functional  areas  through  the  system  and  would  have  to  resort  to 
manual  communications.  With  local  data  entry  using  manually  retrieved  information,  the 
user  has  full  use  of  AFIRMS  tools  normally  available.  From  a  system  point  of  view,  if  the 
central  location  at  a  particular  site  goes  down,  that  site  is  not  functioning  within  AFIRMS. 

At  MAJCOM  and  Wing  levels  a  back-up  communications  mode  is  available  through  which  one 
or  more  of  the  functional  areas  operating  independently  of  each  other  can  communicate  with 
the  next  higher  central  location.  However,  HQ  USAF  cannot  receive  MA3COM  reports  if  the 
HQ  USAF  central  location  is  inoperable. 


The  depth  of  this  problem  is  to  be  studied  further  in  the  Analysis  Phase  of  each 
segment,  to  fully  understand  the  interdependencies  of  functional  areas  and  the  percentage 
of  data  affected  when  a  central  location  goes  down.  Appendix  B  lists  data  that  is  used  by 
the  functional  area  at  the  HQ  USAFE  level.  During  the  Anaiysis  Phase  of  the  HQ  USAFE 
segment,  Appendix  B  is  refined  to  include  its  current  cross-reference  between  a  data  item 
and  the  functional  area(s)  using  that  data  item  and  also  that  data  item's  range  of  values 
allowed  at  that  functional  area. 


2«2. 1.2.1  Full  Redundancy.  Full  redundancy  calls  for  all  site  data  to  be  resident  at  each 
functional  area.  One  advantage  to  this  architecture  is  that  software  developed  to  support 
one  functional  area  can  support  all  functional  areas  with  minimal  changes.  Another  is 
that  each  functional  area  can  operate  independently  in  the  event  that  some  data  from 
other  functional  areas  is  inaccessible.  It  may  be  that  some  functional  areas  will  be  forced 
to  operate  in  a  degraded  mode  with  the  data  current  as  of  the  outage.  Reportability  is 
also  very  strong  in  this  situation,  since  data  can  be  generated  and  received  at  almost  any 
functional  area  that  survives.  The  disadvantages  include  a  marked  increase  in  required 
storage  capacity  at  all  functional  areas  and  increased  communications  traffic  whenever 
updates  occur,  making  this  alternative  unfeasible. 

2.2. 1.2.2  Entity  Redundancy.  Entity  redundancy  is  based  on  the  assumption  that  if  a 
functional  area  requires  any  use  of  a  particular  data  attribute  (field),  the  attribute,  along 
with  its  associated  attributes  grouped  within  entity  classes,  resides  at  the  functional 
area.  This  redundancy  exists  regardless  of  whether  the  entire  entity  class  is  used  by  the 
functional  area.  Updates  to  the  data  attributes  within  the  entity  classes,  when  initiated 
by  other  functional  areas,  are  transmitted  from  the  central  location.  The  possible  result 
is  unnecessary  communication  and  data  storage  costs.  Unnecessary  in  the  sense  that  some 
data  resides  and  is  maintained  at  functional  areas  with  the  possibility  of  never  being  used 
by  some  functional  areas. 


For  example.  Figure  2-1  shows  an  excerpt  of  Base-oriented  data  grouped  in  table 
format.  Included  are  the  BASE  NAME,  BASE  OVERALL  STATUS,  COMM  STATUS 
(Communications),  MX  STATUS  (Maintenance),  and  the  BASE  ETIC.  All  columns 
(attributes)  in  the  table  describe  a  particular  base,  hence,  what  is  shown  is  the  BASE 
entity  class.  In  entity  redundancy,  all  columns  of  an  entity  reside  at  every  functional  area 
at  the  site  where  any  columns  of  the  entity  are  used. 
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Figure  2-1.  Entity  Redundancy 


2.2.1.2.3  Attribute  Segmentation.  Attribute  segmentation  is  a  further  refinement  of 
entity  redundancy.  Accordingly,  this  alternative  is  based  on  the  assumption  that  only 
relevant  entity  classes  reside  at  a  functional  area.  Of  those  entity  classes,  only  those 
attributes  that  are  used  by  the  functional  area  reside  there.  This  concept  further  reduces 
functional  area  storage  requirements  and  communication  costs  between  the  functional 
area  and  the  central  location.  However,  this  reduction  is  accommodated  only  by  greater 
processing  requirements  at  the  central  location.  Software  is  required  at  the  functional 
areas  and  the  central  location  in  order  to  handle  the  logic  required  for  transmitting  and 
receiving  the  updates  to  certain  data  attributes. 

This  alternative  is  the  initial  database  architecture  for  AFIRMS  due  to  its  relatively 
lower  software  development  and  physical  storage  costs.  However,  there  is  still  the 
possibility  that  the  data  redundancy  inherent  to  this  architecture  causes  unnecessary 
communications  and  storage  costs.  Unnecessary  in  the  sense  that  there  are  values  of 
attributes  (residing  at  functional  areas)  that  are  possibly  never  used.  Consequently,  these 
attributes  are  also  updated  upon  change  by  the  owning  functional  area.  Software 
development  costs  are  quite  lower  than  for  record  segmentation  and  record/attribute 
segmentation,  and  not  much  less  than  for  full  or  entity  redundancy.  Storage  costs  are 
much  less  than  for  full  and  entity  redundancy  and  relatively  equal  to  costs  for  record 
segmentation.  However,  storage  requirements  are  somewhat  greater  for  attribute 
segmentation  than  for  record/attribute  segmentation.  Attribute  segmentation  can  also  be 
gradually  evolved  into  a  record/attribute  segmentation  architecture  by  adding  a  layer  of 
software  and  instituting  virtually  no  changes  to  the  existing  software. 
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For  example,  Figure  2-2  shows  an  example  of  attribute  segmentation.  If  a  functional 
area  only  needs  to  view  COMM  STATUS  and  BASE  ETIC  information  (in  the  highlighted 
boxes)  from  the  entity,  that  is  what  resides  there.  Of  course,  the  key  to  the  entity,  in  this 
case  BASE  NAME,  must  also  reside  at  the  functional  area.  Note  that  all  values  in  the 
designated  columns  reside  there  whether  or  not  they  are  all  used. 
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Figure  2-2.  Attribute  Segmentation 


2.2. 1.2.4  Record  or  Tuple  Segmentation.  Record,  or  tuple  in  a  relational  implementation, 
segmentation  is  also  a  further  refinement  of  entity  redundancy.  Only  those  records  that 
possess  keys  with  relevant  values  reside  at  the  functional  area.  Storage  and  communications 
costs  are  significantly  lower  than  for  a  full  or  entity  redundancy  implementation.  These 
costs  are  relatively  equal  to  attribute  segmentation  storage  and  communications  costs,  but 
the  software  required  to  manage  data  communications  is  somewhat  more  complex.  Storage 
costs  are  greater  than  for  a  record/attribute  segmentation  implementation,  but  the  software 
development  required  is  less  complex.  There  also  exists,  with  this  alternative,  the  possibility 
that  unnecessary  data  at  the  functional  areas  must  incur  storage  costs  and  communications 
costs  to  maintain  it.  Furthermore,  record  segmentation  is  more  complex  to  implement  than 
attribute  segmentation  and  is,  therefore,  deemed  less  feasible. 


Figure  2-3  shows  an  example  of  record  or  tuple  segmentation.  If  a  functional  area  needs 
to  view  data  about  only  certain  bases,  all  data  pertaining  to  those  bases  resides  at  the 
functional  area,  as  shown  by  the  highlighted  box.  All  columns,  or  attributes,  of  the  entity 
that  pertain  to  the  desired  bases  will  reside  at  the  functional  area,  whether  or  not  they  are 
all  used. 
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Figure  2-3.  Record  or  Tuple  Segmentation 


2.2. 1.2.3  Record/ Attribute  Segmentation.  This  architecture  is  another  refinement  of  entity 
segmentation,  and  employs  the  concepts  of  attribute  and  record  segmentation.  Only  those 
records  that  possess  keys  with  relevant  values,  such  as  in  record  segmentation,  and  only  those 
relevant  attributes  within  each  record  or  tuple  reside  at  a  functional  area,  such  as  in 
attribute  segmentation.  In  essence,  this  architecture  is  the  result  of  the  intersection  of  the 
attribute  and  record  segmentation  concepts.  For  example  Figure  2-4  shows  an  example  of 
record/attribute  segmentation.  Only  the  COMM  STATUS  and  BASE  ETIC  attributes  of  the 
base  shown  in  the  highlighted  boxes  are  used  by  a  particular  functional  area.  In  this 
architecture,  that  data  is  all  that  needs  to  reside  there. 


With  this  alternative,  storage  and  communications  costs  are  minimized.  But  the 
functional  area  is  still  able  to  operate  independently  in  a  degraded  mode.  However,  software 
development  and  processing  costs  at  the  central  location  are  highest  with  this  alternative. 
Record/Attribute  segmentation  should  be  the  ultimate  goal  of  the  AFIRMS  database 
architecture,  but  it  is  unfeasible  to  implement  in  the  initial  block  due  to  high  data  analysis 
and  software  development  costs.  This  architecture  can  be  reached  through  an  evolutionary 
implementation  from  the  attribute  segmentation  architecture  if  desired. 


OVERALL 

COMM 

BASE  NAME 

STATUS 

STATUS 

MX  STATUS 

BASE  ETIC 

I  BITBURG 


HAHN 


SPANGDAHLEM 


I  061200ZMay  I 


LOP 

LOP  FOP 

FOP 

FOP  FOP 

Figure  2-4.  Record/Attribute  Segmentation 
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2,2.2  AFIRMS  Database  Architecture.  During  the  Analysis  Phase  of  the  initial  block  of 
each  segment,  it  is  to  be  determined  which  of  the  two  architectures  --  attribute 
segmentation  or  record/attribute  segmentation  —  will  be  implemented  MAJCOM-wide. 
The  choice  will  not  affect  other  MAJCOMs  or  the  HQ  USAF  since  record/attribute 
segmentation  is,  actually,  a  more-refined  attribute  segmentation  approach.  It  may  be 
that  an  architecture  employing  record/attribute  segmentation  is  the  ultimate  goal  of  the 
AFIRMS  database  design  in  a  particular  MA3COM,  but  attribute  segmentation  is  desirable 
initially.  This  approach  will  allow  more  functional  areas  within  a  MA3COM  to  become 
operational  earlier,  and  wll  permit  more  time  for  analysis  of  data  requirements  of 
individual  functional  areas.  A  database  architecture  using  attribute  segmentation  is  more 
readily  adaptable  to  an  orderly  accommodation  of  additional  functional  requirements, 
from  a  database  design  and  software  development  point  of  view.  These  additional  data 
needs  are  accommodated  by  trading  off  the  more  global  view  in  favor  of  a  more 
specifically  relevant  local  view. 


Assuming  attribute  segmentation  is  used  initially,  a  central  location  houses  a  copy  of 
the  database.  Each  functional  area  that  participates  in  AFIRMS  also  has  a  database 
locally  resident  on  its  own  AFIRMS  hardware.  In  general,  the  characteristics  of  the  data, 
as  well  as  the  data  structures  and  relationships,  are  identical  wherever  they  reside  at  the 
MAJCOM.  This  is  true  regardless  of  the  data  management  or  database  management 
software  employed,  provided  the  conceptual  data  models,  such  as  the  IDEF-1  model  shown 
in  the  Data  Requirements  Document,  used  by  the  software  are  identical. 


For  example,  in  Figure  2-5  a  simplified  HQ  USAFE-level  database  is  shown  to  include 
three  different  entity  classes  in  the  central  database;  Air  Force  Unit,  Base,  and  Unit's 
Piece  of  Order  (Task).  Note  the  relationships  of  the  entity  classes;  an  Air  Force  Unit  is 
located  at  one  or  more  bases  with  one  or  more  tasks  assigned  to  each  unit.  In  this  case, 
two  functional  areas.  Communications  (COMM)  and  the  Battle  Staff  (BS),  use  all  or  parts 
of  the  central  database;  hence,  all  or  parts  of  the  central  database  reside  at  the  two 
functional  areas  for  speed  of  access.  The  BS  needs  to  view  products  that  use  unit,  base, 
and  task  data;  but  COMM  only  views  products  that  use  unit-  and  base-specific  data.  The 
data  that  resides  in  both  functional  areas  has  characteristics  and  relationships  identical  to 
the  data  that  resides  in  the  central  database.  If  a  base's  communication  status  changes  it 
is  updated  by  COMM  to  indicate  such,  then  that  update  is  transmitted  to  the  central 
database,  where  the  base  record  is  updated.  Finally,  the  updated  base  information  is  then 
transmitted  to  the  BS. 
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By  retaining  the  same  conceptual,  logical  and  physical  data  models  throughout  a 
segment  within  the  EIP,  implementation  of  the  following  areas  is  enhanced: 

1)  data  analysis  in  the  Analysis/Requirements  Definition  Phase; 

2)  software  development  in  the  Development  Phase; 

3)  installing  software,  testing  software,  and  training  in  the  Installation  Phase; 

4)  software  and  database  maintenance  in  the  Operations  Phase. 

2.3  Special  Instructions.  This  section  describes  the  desired  capabilities  of  AFIRMS 
including  data  currency,  ad  hoc  query,  what-if  capability,  reporting,  backup,  archiving, 
and  restoration  as  well  as  issues  concerning  data  redundancy,  normalization,  and  data 
models.  Suggestions  are  made  in  these  areas  and  information  and  guidelines  are  given  to 
aid  in  the  selection  of  DBMS  cind  other  data  management  software  for  implementation  at 
a  specific  site. 

2.3.1  Data  Currency.  When  changes  are  made  to  data  at  the  functional  area  level,  those 
changes  are  transmitted  to  the  central  database.  After  the  central  database  is  updated, 
the  changes  are  subsequently  transmitted  to  other  functional  areas  having  the  data  in 
question  resident  on  their  local  database.  The  time  required  to  complete  the  transactions 
on  the  central  database  and  all  affected  functional  areas  determines  the  currency  of  data. 

Within  a  site  this  time  period  must  be  less  than  three  minutes  for  mission-related 
data  90%  of  the  time  with  the  system  operating  in  a  normal  mode.  AFIRMS 
mission-related  data  consists  of  current  tasking  and  current  primary  resource  status 
information  or  that  data  associated  with  a  crisis  mode.  Primary  resources  are  those 
resources  directly  utilized  by  the  capability  assessment  model. 

Data  currency  at  the  MAJCOM  must  be  achieved  within  one  hour  for  AFIRMS 
non-mission-related  data  90%  of  the  time  with  the  system  operating  in  a  normal  mode. 
AFIRMS  non-mission-related  data  consists  of  that  information  relating  to  ad  hoc,  historic, 
exercise,  or  contingency  simulations  which  are  not  designated  as  current  exercises/crises. 


Data  currency  between  the  WING  and  MA3COM  level  must  be  achieved  within  six 
hours  90%  of  the  time  when  the  system  is  operating  in  normal  mode.  Data  currency 
between  the  MAJCOM  and  HQ  USAF  level  is  achieved  within  twelve  hours  90%  of  the 
time  when  the  system  is  operating  in  normal  mode. 

2.3.2  Ad  Hoc  Query.  Users  need  to  execute  ad  hoc  queries  against  on-line  databases 
which  they  are  allowed  to  access.  Ad  hoc  querying  is  constrained  by  AFIRMS  security  and 
control  requirements.  This  capability  is  limited  to  databases  located  at  the  functional 
area  and  the  central  location.  Ad  hoc  queries  cannot  be  requested  by  HQ  USAF  from  the 
MAJCOM's  databases.  Controls  within  the  DBMS  and  security  software  are  used  to  limit 
access  to  both  the  functional  area  and  central  database  on  a  user-by-user  basis. 

The  ad  hoc  query  access  is  provided  by  the  AFIRMS  executive.  The  user  has  the 
ability  to  interactively  query  the  database  via  an  "English-like"  AFIRMS  query  utility. 

The  user  does  not  have  the  ability  to  update  any  data  while  in  this  mode.  Ad  hoc  queries 
are  limited  to  current  or  crisis  mode  data  only.  When  data  is  requested,  if  it  is  not 
present  in  the  local  functional  area  database,  the  request  is  transmitted  to  the  central 
node.  The  request  is  then  processed  at  the  central  node  and  the  results  returned  to  the 
requesting  functional  area  for  display.  Different  data  management  software  may  be 
involved  in  the  request.  If  so,  the  syntax  translation  between  the  query  languages 
embedded  within  each  set  of  software  is  transparent  to  the  user. 

2.3.3  What-if  Capability.  A  what-if  capability  exists  in  AFIRMS  to  enable  certain  users 
to  input  hypothetical  tasking,  resource,  or  operations  scenarios  to  better  predict  future 
readiness  capability.  The  data  is  input  into  the  local  database  through  a  highly  structured 
AFIRMS  environment.  The  what-if  capability  of  AFIRMS  directly  affects  the  amount  of 
data  redundancy  necessary  at  the  MA3COM  and,  accordingly,  the  amount  of  physical 
storage  capacity  necessary  to  handle  it.  What-if  data  storage  needs  vary  according  to  the 
level  in  the  command  structure  and  the  functional  users'  what-if  exercise  needs.  For 
example,  a  MA3COM  needs  wing  level  resource  summary  status  data  to  simulate 
hypothetical  situations.  Appropriate  storage  capacity  must  be  locally  available  to 
accommodate  all  wings  in  the  MAJCOM.  This  generates  a  need  for  larger  physical 
storage  requirements  at  higher  levels  than  at  lower. 


Wings  require  the  least  amount  of  physical  storage  for  what-if  capability,  MAJCOM 
require  considerably  more,  but  needs  vary  by  MA3COM.  For  example,  in  USAFE  it  is 
estimated  that  the  MAJCOM  requires  at  least  30  times  as  much  data  storage  to 
accommodate  input  and  output  data  for  the  Sortie  Generation  and  Dollars-to-Readiness 
Models  as  does  a  typical  wing  under  USAFE's  command.  This  is  due,  in  part,  to  sortie 
generation  model  runs  of  as  many  as  80  wings'  of  information  at  the  MAJCOM,  and  the 
fact  that  the  Dollars-to-Readiness  function  is  not  available  at  the  wing  level. 


2,3.4  Reporting.  Reporting  of  a  lower  site  to  a  site  higher  in  the  command  structure  is 
accommodated  by  similar  database  architectures  at  the  different  levels.  Data  formats 
and  structures  exist  at  both  sites  in  order  to  facilitate  report  transmissions.  Reports 
occur  on  a  periodic  basis  as  well  as  on  an  "as-needed"  basis.  The  data  involved  in  these 
intersite  reports  describes  the  status  of:  wing  summary  resourcefs),  basefs),  and  unit(s). 


2.3.5  Data  Redundancy.  Data  redundancy  at  the  MAJCOM  is  kept  to  a  minimum. 
Sometimes,  however,  retrieval  speed  becomes  an  important  requirement  and  a  level  of 
redundancy  must  be  introduced  to  accommodate  it.  The  AFIRMS  LPP  has  demonstrated 
need  for  such  data  redundancy  and  the  minimum  local  redundancy  architecture  handles 
this  need.  Analysis  performed  in  the  initial  block  of  each  segment  identifies  the  data 
items  needed  most  by  different  functional  areas,  how  often  they  are  required,  and  who  is 
responsible  for  maintaining  them.  The  database  designer  must  have  this  information  in 
order  to  effect  a  design  under  the  chosen  architecture. 

Redundancy  of  data  between  lower  and  higher-level  sites  is  required  for  the  report 
function.  If  data  communications  are  hindered  among  sites,  but  manual  communications 
are  available,  the  higher  site  can  still  operate  based  on  the  last  reported  summary  data. 
This  type  of  redundancy  is  only  for  data  reported  on  a  regular  or  as-needed  prepackaged 
basis.  Ad  hoc  querying  of  lower  sites  is  not  permitted  within  AFIRMS. 

At  a  MAJCOM,  each  functional  area  has  locally  stored  data  it  needs  on  a  regular 
basis.  This  database  is  composed  of  real,  exercise,  POM,  and  OPlan  data.  The  exercise, 
POM,  OPlan,  and  ad  hoc  tasking  data  comprise  the  what-if  data  present  at  the  MAJCOM 
level.  There  is  a  total  of  five  what-if  databases  permitted  to  be  stored  on-line,  plus  one 
database  storing  actual  current  data,  for  a  total  of  six. 
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The  following  shows  a  sample  breakdown  of  copies  of  AFIRMS  data  resident  at  the 
MAJCOM: 

1  copy  of  current  real  data 

5  copies  of  what-if  data  consisting  of 

2  copies  of  1  exercise  database  (1  beginning  copy  and  1  ending  copy) 

5  databases  depicting  results  of  Sortie  Generation  and  Doilars-to-Readiness 
Models  runs  against  the  ROMs,  OPlans,  and  hypothetical  tasking. 

Since  there  is  a  maximum  of  5  copies  of  what-if  databases  on-line  any  two  of  the  7 
must  reside  off  line,  at  the  discretion  of  the  MA3COM. 


2.3.6  Database  Backup,  Archiving,  and  Restoration.  Backup  of  the  AFIRMS  database  to 
off-line  media  at  the  central  location  occurs  on  a  regularly  scheduled  basis  but  not  less 
than  daily.  Archiving  of  data  from  the  central  database  deemed  impx^rtant  to  off-line 
media  occurs  upon  user  request.  Restoration  of  specific  data  sets  also  occurs  upon  user 
request.  The  regular  schedule  for  backups  of  the  AFIRMS  databases  to  off-line  media  at 
MAJCOM  is: 

1)  At  the  end  of  each  working  day;  retained  for  5  working  days 

2)  At  the  end  of  each  week;  retained  for  5  weeks 

3)  At  the  end  of  each  month;  retained  for  12  months 

4)  At  the  end  of  each  year;  retained  for  5  years. 

The  data  involved  in  the  backup  schedule  above  is  used  for  historical  purposes  also. 
Moreover,  data  can  be  backed-up  on  an  "as-needed"  basis.  An  example  of  this  occurs 
during  exercise  mode  or  crisis  situation  when  AFIRMS  is  being  used  outside  the  normal 
usage  periods,  for  instance,  on  a  weekend.  Normally,  the  database  is  not  automatically 
backed-up  on  the  weekend,  but  in  this  situation  backup  is  manually  initiated  as  required  by 
the  functional  area  user.  Archiving  occurs  in  the  same  manner;  it  is  initiated  manually. 
The  difference  is  that  archived  data  is  not  deleted  from  off-line  media  unless  explicitly 
requested.  For  this  reason  archiving  is  a  tool  that  is  to  be  used  sparingly  for  important 
data.  Archiving  is  initiated  as  required  by  the  functional  area  user.  Restoration  occurs  if 
data  in  the  database  or  transactions  on  the  data  have  been  lost.  Whenever  a  transaction 
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occurs  in  the  local  database,  it  is  logged  to  an  on-line  journal  file  for  use  in  the  event 
restoration  is  needed.  Restoration  consists  of  reloading,  if  necessary,  the  latest  copy  of 
the  database  from  off-line  media  and  applying  the  journal  log  file  to  it. 


2.3.7  External  Interfaces.  It  is  desired,  whenever  possible,  for  AFIRMS  to  have 
direct-line  interfaces  to  other  systems'  data  that  is  useful  to  AFIRMS  on  a  regular  basis. 
There  are  circumstances,  however,  where  a  direct-line  interface  is  not  feasible  due  to 
hardware,  software,  or  security  constraints.  For  example,  as  a  classified  NATO  system, 
the  EIFEL  system  currently  operating  in  USAFE  is  prohibited,  for  security  reasons,  from 
being  physically  connected  to  classified  USAF  ADP  systems.  If  it  is  subsequently  deemed 
necessary  to  have  an  interface  between  AFIRMS  and  EIFEL,  it  must  be  by  an  "airgap," 
i.e.,  hardcopy,  magnetic  tape,  or  floppy  disk.  During  an  interface  transaction,  only  that 
data  which  has  changed  since  the  previous  interface  is  updated  in  the  AFIRMS  database. 
For  example,  in  an  AFIRMS/Air  Force  Operations  Resource  Management  System 
(AFORMS)  interface,  only  that  event  data  for  an  aircrew  member  which  has  changed  since 
the  last  interface  is  included  in  a  transaction  to  the  AFIRMS  database. 


2.3.8  Normalization  and  Data  Models.  Normalization  is  a  technique  of  relating 
functionally  dependent  data  for  ease  of  understanding  and  operationally  maintaining  data 
integrity.  Normalization  is  a  good  starting  point  for  any  database  design  because, 
although  normalization  adapts  most  readily  to  the  relational  data  model,  it  characterizes 
relationships  between  data  to  the  extent  where  minimal  changes  are  necessary  to  switch 
to  a  network,  hierarchical,  or  other  data  model.  This  makes  for  ease  of  adaptability 
between  MAJCOMs  during  the  Analysis  Phases  of  their  block  implementations. 

Each  of  the  logical  data  models— network,  hierarchical,  and  relational— has  inherent 
advantages  and  disadvantages.  Network  logical  data  models  have  the  speed  and  flexibility 
to  work  in  almost  any  application  but  are  very  difficult  to  implement  effectively  and  are 
not  at  all  flexible  if  the  need  for  database  reorganization  arises.  Hierarchical  logical  data 
models  are  usually  a  good  choice  for  a  hierarchically  structured  application,  but  they  are 
not  very  flexible.  While  AFIRMS  is  hierarchical  in  organization,  the  variability  of  data 
requirements  among  functional  users  requires  significant  data  structure  flexibility.  This 
is  particularly  true  when  the  evolutionary  nature  of  the  AFIRMS'  implementation  is 
considered.  Relational  logical  data  models  are  the  easiest  to  implement  and  are  very 
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flexible.  However,  they  lack  the  access  speed  of  some  of  the  other  models.  Other  hybrid 
models  such  as  inverted  files  have  greater  speed  then  relational  models  do,  but  also  possess 
limited  flexibility.  During  the  AFIRMS  LPP,  it  became  apparent  that  flexibility  and  relative 
ease  of  implementation  weigh  heavily  in  the  AFIRMS  development  environment.  In  this 
sense,  the  use  of  a  relational  DBMS  was  of  great  value. 


2.3.9  DBMS  Characteristics.  This  section  lists  the  desired  characteristics  of  a  DBMS  for 
AFIRMS  in  order  of  highest  to  lowest  priority.  Some  characteristics  will  differ  in  degree  of 
relevance  between  MAJCOMs  and  should  be  re-prioritized  accordingly  during  the  Analysis 
Phase  of  the  first  blocks  of  the  operational  system.  The  DBMS  should  support  or  provide: 


Highest. 

(1)  Access  by  multiple  users  from  interactive  and  batch  processes  for  both 
update  and  retrieval  of  information. 

(2)  Application  program  data  independent  of  the  physically  stored  data 
structures. 


(3)  A  database  creation  facility  for  the  initialization  and  loading  of  the 
database. 


(4)  Interaction  with  higher-order  languages  (HOLs). 

(5)  An  English-like  query  language  to  process  data  in  any  file  using  the  DBMS. 

(6)  Creation  of  the  query  must  be  supported  by  a  dictionary  facility  to  inform 
the  user  of  the  permitted  views  and  to  permit  selection  of  the  data 
elements  to  be  reported. 

(7)  A  query  language  that  provides  interactive  editing  of  syntax,  terms,  and 
element  names. 


(8)  A  query  language  that  supports  the  use  of  Boolean  operators. 

(9)  Directing  the  results  of  a  query  to  a  file  that  can  be  used  by  other 
applications  or  support  software. 

(10)  The  ability  to  optionally  round  or  truncate  numerical  fields. 

(1 1)  Adding,  deleting,  or  updating  a  record  in  either  batch  or  on-line  mode. 


(12) 


Extending  DBMS  functions  without  changing  or  recompiling  existing 
processes.  Specifically,  the  ability  to  add  functions  to  the  DBMS  without 
affecting  the  user  language  interface.  The  addition  of  these  functions  is 


transparent  to  any  existing  routines  that  have  been  written  in  the  DBMS 
user  language  or  any  other  languages. 
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(13)  A  database  dictionary  capable  of: 

(a)  Describing  databases,  data  elements,  authorized  users,  logical  user 
views,  and  specifying  user  permissions  (read/write/update). 

(b)  Generating  data  definitions. 

(c)  Restricting  access  to  the  database  dictionary  according  to  security 
requirements. 

(d)  Defining  multiple  occurrences  of  data. 

(e)  Modifying  the  database  in  size,  relationships,  access  methods,  or 
fields  per  record  without  requiring  modification  of  application 
programs  for  which  processing  logic  does  not  change. 

Medium. 

(1)  A  logical  comparison  capability  during  search  and  update  functions. 

(2)  Character  string  searches  for  a  record  number  or  a  field  (using 
alphanumeric,  special  characters,  or  wildcard  notation). 

(3)  A  built-in  HELP  capability  accessible  at  any  level. 

(4)  A  query  system  with  the  ability  to  perform  tabulations  and  arithmetic 
functions,  or  interface  with  a  statistical  package. 

(5)  Development  of  a  query  by  menus,  prompting,  and/or  HELP  facilities. 

(6)  The  ability  of  one  query  to  retrieve  data  from  multiple  files  with  a 

database. 

(7)  A  query  language  with  the  ability  to  logically  manipulate  data. 

(8)  A  query  language  with  the  ability  to  perform  grouping  operations  for 

totals,  counts,  or  specified  calculated  fields. 

(9)  The  results  of  a  query  displayed  on  a  screen  to  be  directed  to  a  file  for 
printing  later. 

(10)  The  ability  to  specify  up  to  five  control  break  levels  (subtotals  for  up  to 
ten  columns). 

(1 1)  The  ability  of  a  user  to  store  a  query  and  allow  the  user  or  other  users, 
subject  to  security  constraints,  to  reuse  the  query.  Stored  queries  must 
be  able  to  be  reused  either  in  their  entirety  or  with  the  addition  or 
modification  of  specific  parameters  by  the  current  user,  and  must  be 
indexed  or  cataloged  to  support  menu-driven  retrieval  of  stored  queries. 

(12)  Recovery  and  restart  capabilities  for  the  DBMS  files. 


(13)  Utilities  which  permit  database  reorganization,  dump  and  restore,  and 
usage  statistics. 

(1^)  Interfaces  with  a  report  writer. 

(15)  The  automatic  return  of  disposed  space  (as  in  the  case  of  a  deletion)  to 
the  system  or  the  ability  to  reallocate  space  itself.  This  will  avoid  the 
need  to  compress  or  reorganize  data  elements  in  order  to  recover  disposed 
spaces  (holes). 

c.  Lowest. 

(1)  Unlimited  number  of  records  per  file  within  available  disk  space. 

(2)  Access  of  last  record,  previous  record,  and  next  record. 

(3)  File  searches  containing  at  least  six  search  criteria. 

(4)  The  ability  of  a  query  language  to  decode  fields. 

(5)  A  query  language  which  automatically  aligns  decimal  points  or  other 
punctuation  for  fields. 

(6)  Data  integrity  that  prevents  simultaneous  updates  and  deadlocks,  and 
maintains  the  logical  and  physical  structure  of  the  database. 

(7)  A  capability  under  exclusive  control  of  the  Database  Administrator  to 
repair  a  database  record  that  is  unreadable. 

(8)  The  ability  of  the  host  language  interface  to  accept  asynchronous  requests 
as  well  as  request  cancellations. 

2.4  Security.  Protection  of  the  AFIRMS  database  against  unauthorized  access  or 
modification  is  an  essential  element  in  the  overall  AFIRMS  ADPS  security  program. 

There  are  a  number  of  security  protection  features  required  by  AFR  205-16  that  have  to 
be  present  in  order  to  provide  file  access  control  for  the  MA3COM  AFIRMS  database. 
These  features  must  include  at  least  the  following: 


a.  Terminal  and  user  profiles  indicating  user  and  terminal  clearance  level,  access 
privileges,  and  user/terminal  permissions  (read/write/update). 

b.  The  ability  to  assign  security  classification  levels  to  files  and/or  data  elements. 


c.  The  ability  to  restrict  file  access  based  on  user  and/or  terminal  clearance  level, 
and  need-to-know. 
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The  ability  to  create  and  maintain  an  audit  trail  to  include: 

1.  Record  of  accesses  made  to  files;  how,  and  from  where  these  accesses 
were  initiated. 

2.  Identity  of  user  and  terminal  that  initiated  access. 

3.  Record  of  all  unauthorized  access  attempts. 


SECTION  3.  DATA  DEFINITIONS 


3.1  Data  Files. 

3.1.1  General  Description  of  Data  Files.  Appendices  A  and  B  of  this  document  list  HQ 
USAFE  general  data  requirements  for  the  central  database  and  each  functional  area. 


3. 1 . 1 . 1  Entity  Class  Characteristics.  The  column  designated  appearance  number  in 
Appendices  A  and  B  has  embedded  within  it  the  number  of  the  entity  class  to  which  it 
belongs.  Section  3.2  of  the  Data  Requirements  Document  completely  describes  the 
characteristics  of  each  entity  class  existing  at  HQ  USAFE.  A  listing  of  entity  classes  by 
functional  area  is  developed  in  the  nalysis  phase  of  each  segment. 


3.1.2  Physical  Characteristics  of  Data  Files. 


a.  File  Contents  and  Format.  All  contents  of  AFIRMS  database  files  are  under  the 
control  of  the  DBMS  or  data  management  system  (DMS)  resident  on  the  local 
computers.  They  are  in  a  format  recognized  by  the  DBMS/DMS  and  are 
accessed  via  the  DBMS/DMS. 

b.  Primary  and  Secondary  Storage  Media.  All  AFIRMS  database  files  reside  on 
disk  storage  for  on-line  access  and  magnetic  tape  or  floppy  disk  media  for 
archiving  and  backup, 

c.  Form  of  the  Contents.  The  form  of  the  contents  of  all  AFIRMS  database  files 
is  binary. 


3.1.3  Logical  Characteristics  of  Data  Files.  Appendix  A  lists  and  describes  all 
appearances  of  data  in  the  MA3COM's  central  database  as  referenced  in  the  DRD. 
Appendix  B  lists  and  describes  all  appearances  of  data  by  functional  area. 


3. 1 .3. 1  Appearance  Class  Characteristics.  Each  appearance  class  referenced  in  Appendix 
A  and  B  is  described  completely  in  Section  3.2  of  the  Data  Requirements  Document. 
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3.2  Tables.  Internal  tables  used  to  manage  or  describe  AFIRMS  data  files  are  defined 
during  the  analysis  phase  for  a  specific  block  implementation. 

3.3  Items.  Items  resident  in  the  tables  described  in  Section  3.2  are  defined  during  the 
analysis  phase  for  a  specific  block  implementation. 

3.4  Records  and  Entries.  Records  or  entries  appearing  in  AFIRMS  data  files  are  defined 
during  the  analysis  phase  for  a  specific  block  implementation.. 


SECTION  4.  INTEGRATED  DATABASE 


The  AFIRMS  database  can  be  divided  into  three  different  types:  HQ  USAF,  MAJCOM, 
and  WING.  Data  is  duplicated,  to  some  degree,  between  levels  by  the  reporting  function. 
In  this  sense,  then,  the  AFIRMS  database  is  not  truly  integrated  because  of  data 
redundancy  existing  at  the  different  levels. 

At  the  MAJCOM,  there  exists  a  central  database  connected  to  multiple  functional 
areas.  Each  functional  area  has,  physically  resident  on  its  hardware,  a  database  which 
duplicates  all  or  part  of  the  central  database. 

AFIRMS  is  integrated  in  the  sense  that  duplication  of  manual  data  inputs  is 
minimized  by  the  fact  that  AFIRMS  interfaces  with  other  ADP  systems  to  access 
necessary  data.  Data  inputs  are  “integrated,”  since  they  are  collected  from  multiple 
systems  without  need  for  redundant  AFIRMS  user  input.  These  inputs  are  stored  for  use 
by  AFIRMS  processes.  This  means  that  the  AFIRMS  central  database  is  not  integrated 
within  the  MA3COM  environment  since  the  same  data  is  stored  and  used  at  both  the 
central  and  functional  areas.  However,  the  AFIRMS  central  database  houses  data  from 
different  functional  areas  non-redundantly  and,  therefore,  is  itself  integrated  because 
multiple  functional  users  are  accessing  the  same  data.  Special  problems  such  as  system 
availability  and  retrieval  speed  require  each  functional  area  to  have  data  that  it  routinely 
needs  resident  on  its  own  hardware.  From  this  perspective,  a  central  database  with 
redundant  data  at  the  functional  areas  is  not,  strictly  speaking,  an  integrated  database, 
when  considered  together  even  though  each  (considered  individually)  is  integrated. 

When  one  or  more  users  in  a  subfunctional  area  are  accessing  the  same  database,  then 
that  database  is  also  integrated  because  the  AFIRMS  architecture  prohibits  redundancy 
within  that  functional  area.  This  does  not  preclude  the  possibility  that  the  same  data  is 
duplicated  at  the  central  database  or  another  functional  area. 

To  summarize,  AFIRMS  collects  data  both  as  AFIRMS  inputs  and  via  electronic 
interfaces  with  other  systems.  AFIRMS  stores  this  data  for  use  by  many  different 
functional  users  in  a  collection  of  decentralized  databases,  each  one  of  which  (taken 
alone)  is  an  integrated  database.  However,  the  data  is  redundant  within  and  between 
AFIRMS  sites  as  well  as  between  other  Air  Force  systems.  Therefore,  AFIRMS,  as  a 
system,  does  not  operate  on  a  truly  integrated  database. 


APPENDIX  A/CHGl.  HQ  USAFE  CENTRAL  DATABASE  STORAGE  REQUIREMENTS 


APPBARANCE 

HUHBER 


APPEARANCE  NAME 


UNIT  MISSION 

UNIT  OPERATIONS  ISBirriPIER 
UNIT  SHORT  NAME 

OOLURS  TO  READINESS  IDENTIPIER 
ORDER  IDENTIPIER 
RESOURCE  PRICE  IDENTIFIER 
raUARS  TO  READINESS  RB1ARKS 
RESOURCE  TYPE 
RESOURCE  UNITS  OP  MEASURE 
RESOURCE  TYPE  NEEKD  FOR  A  TASK 
TASK  TYPE  SET  IDENTIPIER 

RESOURCE  PRIORITY  (7  SCL  x  5  MISSION  x  80  WINGS) 

STANDARD  QUANTITY  OP  RESOURCE  REQUIRED 

TASK  PRIORITY  (5  MISSION  X  80  WINGS  x  20  PERIODS) 

TASK  PERIOD  PROM  DAY  (S  MISSION  x  80  WINGS  X  20  PERIODS) 

TASK  PERIOD  TO  DAY 
AIRCRAFT  OMIT  NAME  (100  SQDN) 

AIRCRAFT  HD8  (100  SQDN  x  3  HDB) 

UNIT  NAME  CWNINa  RESOURCE  (80  WINGS) 

RESOURCE  DESIGNATOR  (34  RESOURCES) 

RESOURCE  UNIT  PRICE  (80  WINGS  x  42  RESOURCES) 

RESOURCE  AUTHORIZED  AHOUIR  (42  RESOURCES  X  80  WINGS) 

RESOURCE  DOLURS  REQUIRED  (60  DAYS  X  4  RESOURCES) 

RESOURCE  SET  IDBIfflPIER 
RESOURCE  OOLURS  SHORT 
RESOURCE  CURRENT  AMOUNT 

BASE  NAME  •  UNIT'S  RESOURCE  LOCATION  (8  LOCATIONS  x  80  WINGS) 
RESOURCE  REALLOCATED  AMOUNT  (34  RESOURCES  x  80  WINGS) 

RESOURCE  ROU-OP  OTG  ((RBSOURCE/UNIT/BASB  :  3)  3  z  80  WINGS) 
RESOURCE  TRANSMIT  DfTG 

AIRCREWS  HR  (80  WINGS  «  100  UNIT  STATUS  APPEARANCES) 

AIRCRAFT  NC 
RESOURCE  RB1ARKS1 
RESOURCE  SUPPLY  IDENTIFIER 
BASE  NAME 
BASE  TYPE 

BASE  GEOGRAPHIC  AREA 
BASE  OPERATIONAL  STATUS 
BASE  NBC  STATUS 
BASE  ETIC 

BASE  STATUS  RB1ARKS 

BASE  STATUS  AS  OF  DTG 

BASE  SHORT  NAME 

BASE  COUNTRY  NAME 

ORDER  IDENTIFIER 

ORDER  TYPE 

ORDER  ID  NUMBER 

0RDB1  DATE 

ORDER  CHANGE  NUMBER 

0RDB1  CUSSIFICATION 

NUMBER  OF  DAYS  TO  RUN  SGH  MODEL 

SORTIE  GENERATION  MODEL  RUN  RB1ARKS 


SIZE  QUANTITY 


APPENDIX  A/CHGl. 


HQ  USAFE 


CENTRAL  DATABASE  STORAGE  REQUIREMENTS  (Cont 


APPEARANCB  TOTAL 


NUMBER 

APPBARANOB  NAME 

SIZE  QUANTITY 

SIZE 

56A 

TA3KB0  UNIT  NAME 

10 

80 

4800 

560 

UNIT  OROER  lOBirriPIOATION 

23 

80 

11040 

56B 

BASE  NAME  -  UNIT  MPLOyMBIR  UMATION 

15 

80 

7200 

56P 

UNIT  mPLOIMBNT  DAY 

5 

80 

2400 

560 

T  UNIT  DAILY  SORTIE  TASK  (60  DAYS  z  80  VINOS) 

4 

4800 

115200 

56H 

T  UNIT  DAILY  INTBORATBD  SORTIE  OAPABILITY 

4 

4800 

115200 

56J 

UNIT  PLANNED  SORTIE  DURATION 

4 

4800 

115200 

56K 

UNIT  SHIPT  DURATION  (20  PERIODS  z  2  3HIPTS  z  80  VINOS) 

4 

3200 

76800 

56M 

T  UNIT  DAILY  RE3OUR0B  QUANTITY  TASKED  (60  DAYS  z  80  UNITS  z  40  RESOUROBS) 

4 

192000 

4608000 

59B 

UNIT  NAME 

7 

80 

3360 

59C 

UNIT  TURN  TIME  POR  ORDER  (80  VINOS  z  20  PERIODS) 

4 

1600 

38400 

590 

PERIOD  START  DAY  POR  UNIT'S  PIBOB  OP  ORDER 

4 

20 

480 

59B 

PERIOD  END  DAY  POR  UNIT'S  PIECE  OP  ORDER 

4 

20 

480 

59P 

UNIT  HAINT  ATTRIT  RATE  POR  ORDER 

4 

1600 

38400 

590 

MISSION  TYPE 

5 

15 

450 

59H 

UNIT  AIRCRAPT  REPAIR  RATE  POR  ORDER  (20  PERIODS  z  80  VINOS) 

4 

1600 

38400 

591 

UNIT  MIN  TIME  BBTVEBN  TAKEOPPS  (20  PERIODS  z  80  VINOS) 

4 

1600 

38400 

59J 

UNIT  COMBAT  ATTRIT  RATE  POR  ORDER  (20  PERIODS  z  80  VINOS  z  2  <1  ACRPT  ♦  1  ACm>) 

4 

3200 

76800 

59K 

SORTIES  PER  DAY  (20  PERIODS  z  80  VINOS  z  5  MISSIONS) 

4 

8000 

192000 

59L 

MISSION  PRIORITY 

4 

15 

360 

71A 

ORDER  insmiPiBR 

23 

1 

138 

71B 

TASK  PERIOD  START  DAY 

4 

20 

480 

710 

TASK  PERIOD  END  DAY 

4 

20 

480 

710 

RESOURCE  TYPE  REQUIRED  POR  TOTAL  ORDER 

20 

42 

5040 

71E 

RESOURCE  QUAirriTY  REQUIRED  POR  TOTAL  ORDER 

4 

201600 

4838400 

7  IP 

SORTIE  AIRCRAPT  RATE  (60  DAYS  z  3  MD3  z  80  UNITS) 

4 

14400 

345600 

710 

SORTIE  DURATION  (20  PERIODS  z  5  MISSIONS  z  80  UNITS) 

4 

8000 

192000 

71A 

UNIT  NAME  •  POR  TASKED  UNIT 

10 

80 

4800 

730 

RESOURCE  TYPE  3UPF0RTIN0  UNIT  TASK  (42  RESOURCES) 

4 

42 

1008 

730 

T  UNIT  DAILY  RESOURCE  SORTIE  CAPABILITY  (60  DAYS  z  80  VINOS  z  42  RESOURCES) 

4 

201600 

4838400 

73P 

T~UNIT  DAILY  RESOURCE  QUANTITY  CAPABLE 

4 

201600 

4838400 

73L 

imn  RESOURCE  AMOUNT  TASKED  (60  z  80  z  42) 

4 

201600 

4838400 

7AB 

RESOURCE  TYPE  IN  UNIT'S  TASKINO  PIECE 

20 

3900 

468000 

89N 

PLY  DAY  START  (20  PERIODS  z  80  VINOS) 

5 

1600 

48000 

890 

SHIPT  PERCENT  PORHED  AIRCREV  (20  PERIODS  z  80  VINOS  z  2  SHIFTS  PER  PERIOD) 

4 

3200 

76800 

89P 

PLY  DAY  DURATION  (80  VINOS) 

2 

80 

960 

89Q 

SHIFT  START  TIME  (20  PERIODS  z  80  VINOS  z  2  SHIFTS  PER  PERIOD) 

5 

3200 

96000 

96B 

RESOURCE  NAME  (39  RESOURCES) 

23 

39 

5382 

960 

RESOURCE  STATUS  (100  BASES  z  39  RESOURCES) 

3 

3900 

70200 

960 

RESOURCE  ETIC 

11 

3900 

257400 

■  TOTAL  DATA 

SIZE  = 

27162060 

TOTAL  OPERATIONAL 

DATABASE 

SIZE  = 

65188944 

33851 


A-2 


APPENDIX  A.  HQ  USAFE  CENTRAL  DATABASE  STORAGE  REQUIREMENTS  (Continued) 


APPEARANCE 

NUMBS! 

APPEARANCE  NAME 

SIZE 

QUAIfTITY 

TO'-AL 

SIZE 

73E 

UNIT  RESOURCE  REQUIRBiENT  FILLED  (42  HESOUSCGS  x  80  UNITS  x  60  DAIS) 

4 

201600 

4838400 

75F 

T_l«IT  DAILY  RffiOUHCE  OUAMTITT  CAPABIE 

4 

201  600 

4  838400 

73G 

TASKING  DAY 

4 

60 

1  440 

73H 

MISSION  TYPE 

5 

15 

450 

731 

UNIT  RESOURCE  AMOUNT  USED  (60  DAY  x  80  WDIC  x  42  RESOURCES) 

4 

201  600 

4838400 

73J 

UNIT  RESOURCE  AMOUNT  SHORT  (60  DAY  x  80  HING  x  42  RESOURCES) 

4 

201600 

4838400 

73K 

NIUBES  OF  SORTIES  SHORTFALL  DUE  TO  RESOURCES  (60  x  80  x  42) 

4 

201600 

4838400 

73L 

UNIT  RESOURCE  AMOUNT  TASKED  (60  x  83  x  42) 

4 

201600 

4838400 

74  A 

TASKED  UNIT  NAME 

to 

80 

4800 

74C 

TASK  TYPE  IN  UNIT'S  TASKING 

5 

5 

150 

74  E 

TASK  RESOURCE 

23 

42 

5796 

74F 

TASKING  DAY 

4 

60 

1440 

74G 

FLY  DAY  HAVE  (5  HAVES/DAY) 

4 

5 

120 

74H 

DAILY  SORTIE  TASK  TOTAL 

4 

432000 

10368000 

741 

DAILY  TOTAL  SORTIE  RESOURCES  SHORT 

4 

432000 

10368000 

74J 

DAILY  TOTAL  SORTIE  RESOURCES  HtODUCED 

4 

432000 

10368000 

89N 

FLY  DAY  START  (20  PERIODS  x  80  HINGS) 

5 

1600 

48000 

890 

SHIFT  PERCENT  FOIMED  AIRCREW  (20  PERIOIS  x  80  HDICS  x  2  SHIFTS  PER  PERIOD) 

4 

3200 

76800 

89P 

FLY  DAY  DURATION  (80  WnOS) 

2 

80 

960 

890 

SHIFT  START  TIME  (20  PERIODS  x  80  HDICS  x  2  SHIFTS  PHI  PERIOD) 

5 

3200 

96000 

gej 

REOMISmON  UNIT  NAME  (20  REQUISITIOIB  x  80  HBOS) 

10 

1600 

96000 

96A 

BASE  NAME 

15 

100 

9000 

96B 

RESOURCE  NAME  (39  RESOURCES) 

23 

39 

5382 

96C 

RESOURCE  STATUS  (100  BASES  x  39  RESOURCES) 

3 

3900 

70200 

TOTAL  DATA 

SIZE  • 

7381 1 71 8 

TOTAL  OPERATIONAL  DATABASE  SIZE  - 

1 771 481 23 

33851  A-3 


APPENDIX  B/CHGl.  HQ  USAFE  FUNCTIONAL  AREA  DATABASE  STORAGE  REQUIREMENTS 


AIR  LIFT  CONTROL  CENTER  (ALCC) 


APPEARANCE  TOTAL 


NUMBER 

APPEARANCE  NAME 

SIZE 

QUANTITY 

SIZE 

1C 

UNIT  MISSION 

3 

15 

270 

IP 

UNIT  SHORT  NAME 

8 

100 

4800 

13A 

UNIT  NAME  OWNING  RESOURCE 

10 

80 

4800 

13B 

RESOURCE  DESIGNATOR 

20 

34 

4080 

13c 

RESOURCE  AUTHORIZED  AMOUNT 

4 

0 

0 

13H 

RESOURCE  CURRENT  AMOUNT 

4 

1 

24 

BASE  NAME  -  UNIT'S  RESOURCE  LOCATION 

15 

100 

9000 

13P 

AIRCREWS  MR 

4 

0 

0 

13Q 

AIRCRAPT  MC 

4 

0 

0 

53A 

BASE  NAME 

15 

100 

9000 

53B 

BASE  TYPE 

3 

5 

90 

53c 

BASE  GEOGRAPHIC  AREA 

21 

5 

630 

53c 

BASE  GEOGRAPHIC  AREA 

21 

5 

630 

BASE  OPERATIONAL  STATUS 

3 

5 

90 

53D 

BASE  OPERATIONAL  STATUS 

3 

5 

90 

53B 

BASS  NBC  STATUS 

3 

5 

90 

53P 

BASS  BIIC 

11 

100 

6600 

53P 

BASE  STIC 

11 

100 

6600 

53H 

BASE  STATUS  AS  OP  DTO 

10 

100 

6000 

53J 

BASE  SHORT  NAME 

4 

100 

2400 

531C 

BASS  COUNTRY  NAME 

15 

20 

1800 

53K 

BASE  COUNTRY  NAME 

15 

20 

1800 

96B 

RESOURCE  NAME 

23 

39 

5382 

96C 

RESOURCE  STATUS 

3 

3900 

70200 

TOTAL  DATA  SIZE  *  13A376 

TOTAL  OPERATIONAL  DATABASE  SIZE  :  317127 


33851 


B-1 


SOF]eCH 


BATTLE  STAFF  (BS) 


APPBARANCE 

NUMBER  APPEARANCE  NAME 

SIZE  QUANIITY 

TOTAL 

SIZE 

1C 

UNIT  MISSION 

3 

15 

270 

1E 

UNIT  0P8RATI0NS  lOBNTIPIER 

23 

1 

138 

IP 

UNIT  SHORT  NAME 

a 

100 

4800 

8A 

R8S0URC8  TYP8  NEEOBO  POR  A  TASK 

23 

11 

1518 

SB 

TASK  TYP8  SET  lOENTIPIER 

23 

1 

138 

11A 

AIRCRAPT  UNIT  NAME 

10 

100 

6000 

lie 

AIRCRAPT  M08 

7 

50 

2100 

13A 

UNIT  NAME  OWNING  RESOURCE 

10 

80 

4800 

13B 

RESOURCE  OBSIONATOfi 

20 

34 

4080 

13D 

RESOURCE  SET  lOBNTIPIER 

23 

1 

138 

13H 

RESOURCE  CURRENT  AMOUNT 

4 

3360 

80640 

13J 

BASE  NAME  -  UNIT'S  RESOURCE  LOCATION 

15 

100 

9000 

13H 

RESOURCE  ROU-UP  DTO 

13 

240 

18720 

20H 

RESOURCE  SUPPLT  lOENTIPnR 

23 

1 

138 

53A 

BASE  NAME 

15 

100 

9000 

53B 

BASE  TYPE 

3 

5 

90 

53C 

BASE  OSOORAPHIC  AREA 

21 

5 

630 

53D 

BASE  OPERATIONAL  STATUS 

3 

5 

90 

538 

BASE  NBC  STATUS 

3 

5 

90 

53P 

BASE  STIC 

11 

100 

6600 

530 

BASE  STATUS  RBURKS 

140 

100 

84000 

53H 

BASE  STATUS  AS  OP  OTG 

10 

100 

6000 

53J 

BASE  SHORT  NAME 

4 

100 

2400 

53K 

BASE  COUNTRY  NAME 

15 

20 

1800 

54A 

0R08R  lOENTIPIER 

23 

1 

138 

548 

OR08R  DATE 

7 

1 

42 

540 

ORDER  CHANCE  NUMBBl 

4 

1 

24 

54K 

ORDER  CUSSIPICATION 

21 

1 

126 

540 

NUMBER  OP  DAYS  TO  RUN  SOM  MODEL 

4 

10 

240 

54R 

SORTIE  GENERATION  MODEL  RON  RBURKS 

45 

10 

2700 

56A 

TASKED  UNIT  NAME 

10 

80 

4800 

560 

UNIT  ORDER  IDENTIPICATION 

23 

80 

11040 

56E 

BASE  NAME  -  UNIT  BIPLOYNENT  LOCATION 

15 

80 

7200 

56P 

UNIT  EMPLOYMENT  DAY 

5 

80 

2400 

560 

T  UNIT  DAILY  SORTIE  TASK 

4 

4800 

115200 

56H 

T  UNIT  DAILY  INTEGRATED  SORTIE  CAPABIUTY 

4 

4800 

115200 

56J 

UNIT  PUNNED  SORTIE  DURATION 

4 

4800 

115200 

56K 

UNIT  SHIPT  DURATION 

4 

3200 

76800 

56M 

T  UNIT  DAILY  RESOURCE  QUANTITY  TASKED 

4 

1 92000 

4608000 

59B 

UNIT  NAME 

7 

80 

3360 

59C 

UNIT  TURN  TIME  POR  ORDER 

4 

1600 

38400 

590 

PERIOD  START  DAY  POR  UNIT'S  PIECE  OP  ORDER 

4 

20 

480 

598 

PERIOD  END  DAY  POR  UNIT'S  PIECE  OP  ORDER 

4 

20 

480 

59P 

UNIT  MAIN!  ATTRIT  RATE  POR  ORDER 

4 

1600 

38400 

590 

MISSION  TYPE 

5 

15 

450 

59H 

UNIT  AIRCRAPT  REPAIR  RATE  POR  ORDER 

4 

1600 

38400 

591 

UNIT  MIN  TIME  BETWEEN  TAKEOPPS 

4 

1600 

38400 

59J 

UNIT  COMBAT  ATTRIT  RATE  POR  ORDER 

4 

3200 

76800 

59K 

SORTIES  PER  DAY 

4 

8000 

192000 

59L 

MISSION  PRIORITY 

4 

15 

360 

71A 

ORDER  IDBNTIPIER 

23 

1 

138 

71B 

TASK  PERIOD  START  DAY 

4 

20 

480 

SOFfecH 


33861 


B-2 


BATTLE  STAFF  (BS)  (Continued) 


APPEARANCE 

NUMBER  APPEARANCE  NAME 


7 1C  TASK  PERIOD  END  DAY 

7 ID  RESOURCE  TYPE  REQUIRED  POR  TOTAL  ORDER 

71E  RESOURCE  QUANTITY  REQUIRED  POR  TOTAL  ORDER 

71G  SORTIE  DURATION 

73A  UNIT  NAME  -  POR  TASKED  UNIT 

73C  RESOURCE  TYPE  SUPPORTING  UNIT  TASK 

73D  T  UNIT  DAILY  RESOURCE  SORTIE  CAPABILITY 

TAB  RBOURCB  TYPE  IN  UNIT'S  TASKING  PIECE 

89N  PLY  DAY  START 

890  SHIFT  PERCENT  POmED  AIRCREW 

89P  PLY  DAY  DURATION 

89Q  SHIFT  START  TIME 

96B  RESOURCE  NAME 

96C  RESOURCE  STATUS 

96D  RESOURCE  ETIC 


TOTAL 

SIZE  QUANTITY  SIZE 


A  20  A80 

20  A2  50A0 

A  201600  A838AOO 

A  8000  192000 

10  80  A800 

A  A2  1008 

A  201600  A838A00 

20  11  1 320 

5  1600  A8000 

A  3200  76800 

2  80  960 

5  320C  96000 

23  39  5382 

3  3900  70200 

11  3900  257A00 

TOTAL  DATA  SIZE  :  16166628 

TOTAL  OPERATIONAL  DATABASE  SIZE  :  37506576 


I 


B-3 


COMMUNICATIONS  (COMM) 


APPEARANCE  TOTAL 


NUMBER 

APPEARANCE  NAME 

SIZE 

QUANTITY 

SIZE 

53A 

BASE  NAME 

15 

100 

9000 

53B 

BASE  TYPE 

3 

5 

90 

53C 

BASE  CEOGRAPHIC  AREA 

21 

5 

630 

53D 

BASE  OPERATIONAL  STATUS 

3 

5 

90 

53E 

BASE  NBC  STATUS 

3 

5 

90 

53P 

BASE  ETIC 

11 

100 

6600 

53G 

BASE  STATUS  RBURKS 

140 

100 

84000 

53H 

BASE  STATUS  AS  OP  mG 

10 

100 

6000 

53K 

BASE  COUNTRY  NAME 

15 

20 

1800 

96B 

RESOURCE  NAME 

23 

39 

5382 

96C 

RESOURCE  STATUS 

3 

3900 

70200 

96D 

RESOURCE  ETIC 

11 

3900 

257400 

TOTAL  DATA 

SIZE  = 

441282 

TOTAL  OPERATIONAL  DATABASE  SIZE  = 

1041425 

^  i^j  ■  u  if;  j  u>j  hjpvp  <  ■  in  ii  uj  u.i  in  b  ^  u  m  ^  V3  m  m  ^  a  n'  i  ^  i  ii  i 


COMMAND  AND  CONTROL  REPORTS  DIVISION  (DOCR) 


APPBARAMCB  TOTAL 


NUMBER 

APPEARANCE  NAME 

SIZE 

QUANTITY 

SIZE 

1C 

UNIT  MISSION 

3 

15 

270 

IP 

UNIT  SHORT  NAME 

8 

100 

a800 

5AA 

ORDER  IDENTIPIER 

23 

1 

138 

SAB 

ORDER  DATE 

7 

1 

A2 

SAG 

ORDER  CHANQB  NUMBER 

A 

1 

2A 

5AK 

ORDER  CUSSIPICATION 

21 

1 

126 

56G 

T  UNIT  DAILY  SORTIE  TASK 

A 

A  800 

115200 

56H 

T  UNIT  DAILY  INTEGRATED  SORTIE  CAPABILITY 

A 

A800 

115200 

73C 

RESOURCE  TYPE  SUPPORTING  UNIT  TASK 

A 

A2 

1008 

7311 

T  UNIT  DAILY  RESOURCE  SORTIE  CAPABIUTY 

A 

201600 

A838A00 

TOTAL  DATA 

SIZE  = 

5075208 

TOTAL  OPERATIONAL  DATABASE 

SIZE  = 

95921  A3 

c 


>:• 


33861 


B-5 


COMBAT  EMPLOYMENT  CAPABILITY  DIVISION  (D03N) 


APPEARANCE  TOTAL 


NUMBER 

APPEARANCE  NAME 

SIZE 

QUANTITY 

SIZE 

1C 

UNIT  MISSION 

3 

15 

270 

1B 

UNIT  OPERATIONS  lOENTIPIER 

23 

1 

138 

40 

OOLURS  TO  REAOINBSS  REMARKS 

40 

4 

960 

3A 

RESOURCE  TYPE  NEBDEO  POR  A  TASK 

23 

11 

1518 

SB 

TASK  TYPE  SET  lOEWIPIER 

23 

1 

138 

SO 

RESOURCE  PRIORITY 

4 

7 

168 

8E 

STANOARO  QUAmiTY  OP  RESOURCE  RBQUIREO 

4 

1100 

26400 

9B 

TASK  PRIORITY 

4 

8000 

1 92000 

9E 

TASK  PBRIOO  PROM  DAY 

4 

20 

480 

9P 

TASK  PERIOD  TO  DAY 

4 

20 

480 

tIA 

AIRCRAFT  UNIT  NAME 

10 

100 

6000 

lie 

AIRCRAFT  H08 

7 

50 

2100 

13B 

RESOURCE  OBSIOIATOR 

20 

34 

4080 

13CC 

RESOURCE  OOLURS  REQUIRED 

4 

240 

5760 

130 

RESOURCE  SET  IDENTIFIER 

23 

1 

138 

1300 

RESOURCE  OOLURS  SHORT 

4 

240 

5760 

20H 

RESOURCE  SUPPLY  IDENTIFIER 

23 

1 

138 

54A 

ORDER  IDBirriFIBR 

23 

1 

138 

54E 

ORDER  DATE 

7 

1 

42 

540 

ORDER  CHANGE  NUMBER 

4 

1 

24 

54K 

ORDER  CUSSIFICATION 

21 

1 

126 

54Q 

NUMBER  OF  DAYS  TO  RUN  SOM  MODEL 

4 

10 

240 

54fl 

SORTIE  GENERATION  MODEL  RUN  ROIARKS 

45 

10 

2700 

56a 

TASKED  UNIT  NAME 

10 

60 

4800 

560 

UNIT  ORDER  IDENTIFICATION 

23 

80 

11040 

56B 

BASE  NAME  -  UNIT  EnPLOYMEin  LOCATION 

15 

80 

7200 

56P 

UNIT  atPLOYHENT  DAY 

5 

80 

2400 

560 

T  UNIT  DAILY  SORTIE  TASK 

4 

4800 

115200 

56h 

T  UNIT  DAILY  INTEGRATED  SORTIE  CAPABILITY 

4 

4800 

115200 

56j 

UNIT  PUNNED  SORTIE  DURATION 

4 

4800 

115200 

56K 

UNIT  SHIFT  DURATION 

4 

3200 

76800 

56M 

T  UNIT  DAILY  RESOURCE  QUANTITY  TASKED 

4 

192000 

4608000 

590 

PERIOD  START  DAY  POR  UNIT'S  PIECE  OF  ORDER 

4 

20 

480 

59E 

PfflIOD  END  DAI  POR  UNIT’S  PIECE  OF  ORDER 

4 

20 

480 

590 

MISSION  TYPE 

5 

15 

450 

59K 

SORTIES  PER  DAY 

4 

8000 

192000 

59L 

MISSION  PRIORITY 

4 

15 

360 

71A 

ORDER  IDENTIFIER 

23 

1 

138 

71B 

TASK  PERIOD  START  DAY 

4 

20 

480 

7 1C 

TASK  PERIOD  END  DAY 

4 

20 

480 

710 

RESOURCE  TYPE  REQUIRED  POR  TOTAL  ORDER 

20 

42 

5040 

71B 

RESOURCE  QUANTITT  REQUIRED  POR  TOTAL  ORDER 

4 

201600 

4838400 

71P 

SORTIE  AIRCRAFT  RATE 

4 

14400 

345600 

710 

SORTIE  DURATION 

4 

8000 

192000 

73A 

UNIT  NAME  •  FOR  TASKED  UNIT 

10 

80 

4800 

73C 

RESOURCE  TYPE  SUPPORTING  UNIT  TASK 

4 

42 

1008 

730 

T  UNIT  DAILY  RESOURCE  SORTIE  CAPABILITY 

4 

201600 

4838400 

73P 

T  UNIT  DAILY  RESOURCE  QUANTITY  CAPABLE 

4 

201600 

4838400 

73L 

UNIT  RESOURCE  AMOUNT  TASKED 

4 

201600 

4838400 

74B 

RESOURCE  TYPE  IN  UNIT'S  TASKING  PIECE 

20 

42 

5040 

39N 

PLY  DAY  START 

5 

1600 

48000 

890 

SHIPT  PERCENT  PORMBD  AIRCREW 

4 

3200 

76800 

33861 


B-6 


OPERATIONS  PLANS  (CONTINGENCY /EXERCISE/SPECIAL  PLANS)  (DOX) 


APPBARAMCB  ,  TOTAL 


NIMBER 

APPEARANCE  NAME 

SIZE 

QUANTITY 

SIZE 

1C 

UNIT  niSSION 

3 

15 

270 

IB 

UNIT  OPERATIONS  lOeNTIPIBR 

23 

1 

138 

8A 

RESOURCE  TYPE  HEBDBQ  POR  A  TASK 

23 

11 

1518 

SB 

TASK  TYPE  SET  IDENTIFIER 

23 

1 

138 

SB 

RESOURCE  PRIORITY 

A 

7 

168 

SB 

STANDARD  QUANTITY  OF  RESOURCE  REQUIRED 

A 

1100 

26400 

9B 

TASK  PRIORITY 

A 

8000 

192000 

9E 

TASK  PERIOD  FROM  DAY 

A 

20 

480 

9P 

TASK  PERIOD  TO  DAY 

A 

20 

480 

UA 

AIRCRAFT  UNIT  NAME 

10 

100 

6000 

lie 

AIRCRAFT  Hie 

7 

50 

2100 

13D 

RESOURCE  SET  IDENTIFIER 

23 

1 

138 

20H 

RESOURCE  SUPPLY  IDENTIFIER 

23 

1 

138 

54A 

ORDER  IDENTIFIER 

23 

1 

138 

SAB 

ORDBt  DATE 

7 

1 

42 

SAG 

ORDER  CHANGE  NUMBER 

A 

1 

24 

5AK 

ORDER  CUS3IFICATI0N 

21 

1 

126 

5AQ 

HUMBER  OF  DAYS  TO  RUN  SQM  MODEL 

A 

10 

240 

5AR 

SORTIE  GENERATION  MODEL  RUN  RBURKS 

A5 

10 

2700 

56A 

TASKED  UNIT  NAME 

10 

80 

4800 

560 

UNIT  ORDER  IDENTIFICATION 

23 

80 

11040 

56P 

UNIT  EMPLOYMENT  DAY 

5 

80 

2400 

56G 

T  UNIT  DAILY  SORTIE  TASK 

A 

A  800 

115200 

56H 

T  UNIT  DAILY  INTEGRATED  SORTIE  CAPABIUTY 

A 

A800 

115200 

56J 

UNIT  PUNNED  SORTIE  DURATION 

A 

ASOO 

115200 

56K 

UNIT  SHIFT  DURATION 

A 

3200 

76800 

59B 

UNIT  NAME 

7 

80 

3360 

59C 

UNIT  TURN  TIME  FOR  ORDER 

A 

1600 

38400 

590 

PBIIOD  START  DAY  FOR  UNIT'S  PIECE  OP  ORDER 

A 

20 

480 

59E 

PERIOD  END  DAI  FOR  UNIT'S  PIECE  OF  ORDER 

A 

20 

A80 

59P 

UNIT  HAINT  ATTRIT  RATE  FOR  ORDER 

A 

1600 

38400 

59H 

UNIT  AIRCRAFT  REPAIR  RATE  FOR  ORDER 

A 

1600 

38400 

591 

UNIT  MIN  TIME  BETWEEN  TAKEOFFS 

A 

1600 

38400 

59J 

UNIT  COMBAT  ATTRIT  RATE  POR  ORDER 

A 

3200 

76800 

71A 

ORDER  IDENTIFIER 

23 

1 

138 

71B 

TASK  PERIOD  START  DAY 

A 

20 

A80 

71C 

TASK  PERIOD  END  DAY 

A 

20 

A  80 

710 

RESOURCE  TYPE  REQUIRED  FOR  TOTAL  ORDER 

20 

A2 

5040 

71B 

RESOURCE  QUANTITY  REQUIRED  FOR  TOTAL  ORDER 

A 

201600 

4838400 

71P 

SORTIE  AIRCRAFT  RATE 

A 

1AA00 

345600 

71G 

SORTIE  DURATION 

A 

8000 

192000 

73A 

UNIT  NAME  -■  FOR  TASKED  UNIT 

10 

80 

a800 

73C 

RESOURCE  TYPE  SUPPORTING  UNIT  TASK 

A 

A2 

1008 

73D 

T  UNIT  DAILY  RESOURCE  SORTIE  CAPABILITY 

A 

201600 

4838400 

89N 

FLY  DAY  START 

5 

1600 

A8000 

890 

SHIFT  PERCENT  FORMED  AIRCREW 

A 

3200 

76800 

89P 

FLY  DAY  DURATION 

2 

80 

960 

890 

SHIFT  START  TIME 

5 

3200 

96000 

TOTAL  DATA 

SIZE  = 

11356704 

TOTAL  OPERATIONAL  DATABASE 

SIZE  = 

2555258a 

33861 


B-8 


1 


ENGINEERING  AND  SERVICES  READINESS  CENTER  (ESRC) 


APPBARANCS 


TOTAL 


NIMBBR 

APPBARANCB  NAHB 

SIZE 

QUANTITY 

SIZE 

1C 

UNIT  MISSION 

3 

15 

270 

IP 

UNIT  SHORT  NAMB 

8 

A 

192 

53A 

BA3B  NAHB 

15 

100 

9000 

53B 

BASB  TYPB 

3 

5 

90 

53C 

BASE  OEOGRAPHIC  AREA 

21 

5 

630 

53B 

BASE  OPERATIONAL  STATUS 

3 

5 

90 

53B 

BASB  NBC  STATUS 

3 

5 

90 

53P 

BASE  BTIC 

11 

100 

6600 

530 

BASE  STATUS  RBURKS 

1A0 

100 

84000 

53H 

BASB  STATUS  AS  OP  OTO 

10 

100 

6000 

53K 

BASB  COUNTRI  NAME 

15 

20 

1800 

96B 

RESOURCE  NAME 

23 

39 

5382 

96C 

RESOURCE  STATUS 

3 

3900 

70200 

96D 

RESOURCE  STIC 

11 

3900 

257400 

TOTAL  DATA 

SIZE  = 

441744 

TOTAL  OPERATIONAL  DATABASE 

SIZE  = 

834896 

33861 


B-9 


ENERGY  MANAGEMENT  (LGSF) 


APPBARANCK 


TOTAL 


NUMBER 

APPBARAHCB  NAHB 

SIZE 

QUANTITY 

SIZE 

1C 

UNIT  MISSION 

3 

15 

270 

AA 

DOLURS  TO  RBADINBSS  IDBIRIPIBR 

23 

1 

138 

AB 

ORDCR  IKNTIPIER 

23 

1 

138 

AC 

RESOURCE  PRICE  IDBNTIPIBR 

23 

I 

138 

AD 

DOLURS  TO  READINESS  ROIARKS 

AO 

1 

2A0 

5A 

RESOURCE  TYPE 

20 

A2 

5OA0 

11A 

AIRCRAPT  UNIT  NAME 

10 

100 

6000 

lie 

AIRCRAPT  HD8 

7 

50 

2100 

13B 

RESOURCE  DESIGNATOR 

20 

3A 

A080 

13BB 

RESOURCE  UNIT  PRICE 

A 

3336 

8006A 

13CC 

RESOURCE  DOLURS  REQUIRED 

A 

2A0 

5760 

13D 

RESOURCE  SET  IDENTIPIER 

23 

1 

138 

13DD 

RESOURCE  DOLURS  SHORT 

A 

2A0 

5760 

13U 

RESOURCE  RMARKSI 

30 

5A 

9720 

5AA 

ORDER  lOBirriPIER 

23 

1 

138 

SAB 

ORDER  DATE 

7 

1 

A2 

SAG 

ORDER  CHANGE  NUMBER 

A 

1 

2A 

SAK 

ORDER  CUSSIPICATION 

21 

1 

126 

S6A 

TASKED  UNIT  NAME 

10 

80 

A800 

S6E 

BASE  NAME  -  UNIT  EMPLOYMENT  LOCATION 

15 

80 

7200 

S6P 

UNIT  mPLOYMBNT  DAT 

5 

80 

2A00 

S6G 

T  UNIT  DAILY  SORTn  TASK 

A 

A800 

115200 

S6H 

T  UNn  DAILY  INTEGRATED  SORTIE  CAPABILITY 

A 

A800 

115200 

73A 

UNIT  NAME  -  POR  TASKED  UNIT 

10 

80 

A800 

73C 

RESOURCE  TYPE  SUPPORTING  UNIT  TASK 

A 

A2 

1008 

730 

T  UNIT  DAILY  RESOURCE  SORTIB  CAPABILITY 

A 

201600 

A838A00 

TOTAL  DATA  SIZE  : 

TOTAL  OFBRAnONAL  DATABASE  SIZE  : 

520892A 

111A7097 

4 


SUPPLY  MANAGEMENT  (LGSS) 


APPBARANCB 


TOTAL 


NUMBER 

APPBARANCB  NAME 

SIZE 

QUANTITY 

SIZE 

1C 

UNIT  MISSION 

3 

15 

270 

IP 

UNIT  SHORT  NAME 

8 

100 

A800 

AA 

DOLURS  TO  READINESS  IDBIRIPIER 

23 

1 

138 

4B 

ORKR  IDBirriPIBR 

23 

1 

138 

AC 

RESOURCE  PRICE  IDEIRIPIER 

23 

1 

138 

AB 

DOLURS  TO  READINESS  RBIARKS 

AO 

1 

2A0 

5A 

RESOURCE  TYPE 

20 

A2 

50A0 

IIA 

AIRCRAFT  UNIT  NAME 

10 

100 

6000 

nc 

AIRCRAFT  HD6 

7 

50 

2100 

13B 

RESOURCE  DESIGNATOR 

20 

3A 

A080 

13BB 

RESOURCE  UNIT  PRICE 

A 

3336 

8006a 

13CC 

RESOURCE  DOLURS  REQUIRED 

A 

2A0 

5760 

13D 

RESOURCE  SET  lUtlRIFIBR 

23 

1 

138 

131)1) 

RESOURCE  DOLURS  SHORT 

A 

2A0 

5760 

13U 

RESOURCE  RMARKSI 

30 

5A 

9720 

5AA 

ORDER  IDBHTIFIBR 

23 

138 

SAC 

ORDER  TYPE 

7 

1 

42 

SAD 

ORDER  ID  NUMBER 

A 

1 

24 

SAE 

ORDER  DATE 

7 

} 

42 

5AO 

ORDER  CHANGE  NUMBER 

A 

1 

24 

SAK 

ORDER  CUSSIFICATION 

21 

1 

126 

S6A 

TASKED  UNIT  NAME 

10 

80 

A800 

S6P 

UNIT  BIPLOYHEirr  DAY 

5 

80 

2A00 

S60 

T  UNIT  DAILY  SORTIE  TASK 

A 

A800 

115200 

S6H 

T  UNIT  DAILY  INTEGRATED  SORTIE  CAPABILITY 

A 

A800 

115200 

73A 

UNIT  NAME  •  FOR  TASKED  UNIT 

10 

80 

A800 

73c 

RESOURCE  TYPE  SUPPORTING  UNIT  TASK 

A 

A2 

1008 

73D 

T  UNIT  DAILY  RESOURCE  SORTIE  CAPABIUTY 

A 

201600 

A838A00 

TOTAL  DATA 

SIZE  : 

5206590 

TOTAL  OPERATIONAL  DATABASE  SIZE  : 

1A266056 

MUNITIONS  REQUIREMENTS  DIVISION  (LGWR) 


APFBARANCB  TOTAL 


NUMBER 

APFBARANCB  NAMB 

SIZE 

QUANTITY 

SIZE 

1C 

UNIT  MISSION 

3 

15 

270 

AA 

DOLURS  TO  RBADINBSS  lOBNTIPIER 

23 

1 

13s 

4B 

ORDER  IDBIRIPIER 

23 

1 

138 

AC 

RESOURCE  PRICE  IDBHTIPIER 

23 

1 

138 

AD 

ULURS  TO  READINESS  RBURKS 

AO 

1 

2A0 

5A 

RESOURCE  TYPE 

20 

A2 

50A0 

11A 

AIRCRAFT  UNIT  NAMB 

10 

100 

6000 

lie 

AIRCRAFT  HDB 

7 

so 

2100 

13B 

RESOURCE  DE3I0NAT0R 

20 

3A 

A080 

13BB 

RESOURCE  UNIT  PRICE 

A 

3336 

80064 

13CC 

RESOURCE  DOLURS  REQUIRED 

A 

2A0 

5760 

13D 

RESOURCE  SET  IDENTIFIER 

23 

1 

138 

13DD 

RESOURCE  DOLURS  SHORT 

A 

2A0 

5760 

130 

RESOURCE  RWARKSI 

30 

5A 

9720 

54A 

ORDB  IDENTIFIER 

23 

1 

138 

SAB 

ORDER  DATE 

7 

,  1 

42 

SAG 

ORDER  CHANGE  NUMBER 

A 

‘  1 

24 

5AK 

ORDER  CUSSIFICATION 

21 

1 

126 

56A 

TASKED  UNn  NAMB 

10 

SO 

4800 

56P 

WIT  EMPLOIMENI  DAY 

5 

so 

2400 

560 

T  WIT  DAILY  SORTIE  TASK 

A 

asoo 

115200 

56H 

T  WIT  DAILY  INTEGRATED  SORTIE  CAPABIUTY 

A 

asoo 

115200 

73A 

UNIT  NAME  -  FOR  TASKED  WIT 

10 

so 

4800 

73c 

RESOURCE  TYPE  SUPPORTINO  WIT  TASK 

A 

A2 

1008 

7  3D 

T  Wn  DAILY  RESOURCE  SORTIE  CAPABILITY 

A 

201600 

4838400 

TOTAL  DATA 

SIZE  : 

5201724 

TOTAL  OPERATIONAL  DATABASE 

SIZE  : 

11703879 

33861 


B-i2 


LOGISTICS  PLANS  (LGX) 


I 

I 

s 

I 

I 

t- 

I 

I 


APPEARANCE 


NUHBER 

APPEARANCE  NAME 

SIZE 

QUANTITI 

SIZE 

54A 

ORDER  lOBmiFIER 

23 

1 

138 

54E 

ORDER  DATE 

7 

1 

42 

540 

ORDER  CHANGE  NUHBER 

4 

1 

24 

54K 

ORDER  CUSSIPICATION 

21 

1 

126 

59B 

UNIT  NAHE 

7 

80 

3360 

59C 

UNIT  TURN  TIKE  POR  ORDER 

4 

1600 

38400 

59D 

PERIOD  START  DAI  POR  UNIT'S  PIECE  OP  ORDER 

4 

20 

480 

59B 

PERIOD  END  DAI  POR  UNIT'S  PIECE  OP  ORDER 

4 

20 

480 

59P 

UNIT  HAINT  ATTRIT  RATE  POR  ORDER 

4 

1600 

38400 

59H 

UNIT  AIRCRAFT  REPAIR  RATE  POR  ORDER 

4 

1600 

38400 

591 

UNIT  HIN  TIKE  BETWEEN  TAKEOFFS 

4 

1600 

38400 

59J 

UNIT  COHBAT  ATTRIT  RATE  POR  ORISR 

4 

3200 

76800 

TOTAL  DATA 

SIZE  = 

235050 

TOTAL  OPERATIONAL  DATABASE 

SIZE  = 

444244 

] 


'OFfeCH 


33861 


LOGISTICS  READINESS  CENTER  (LRC) 


APPSARANCB 


TOTAL 


NUMBER 

APPEARANCE  NAME 

SIZE 

QUANTITY 

SIZE 

1C 

UNIT  MISSION 

3 

15 

270 

IP 

UNIT  SHORT  NAME 

8 

100 

4800 

5A 

RESOURCE  TYPE 

20 

A2 

50AO 

5B 

RESOURCE  UNITS  OP  MEASURE 

8 

5 

2A0 

11A 

AIRCRAPT  UNIT  NAME 

10 

100 

6000 

nc 

AIRCRAPT  HOS 

7 

SO 

2100 

13A 

UNIT  NAME  OWNING  RESOURCE 

10 

80 

4800 

13B 

RESOURCE  DESIGNATOR 

20 

3A 

4080 

13c 

RESOURCE  AOTHORIZED  AMOUNT 

A 

3360 

80640 

13D 

RESOURCE  SET  IDBNTIPIER 

23 

1 

138 

13H 

RESOURCE  CURRENT  AMOUNT 

A 

3360 

80640 

13J 

BASE  NAME  -  UNIT'S  RESOURCE  LOCATION 

15 

100 

9000 

13K 

RESOURCE  REALLOCATED  AMOUNT 

A 

2720 

65280 

13N 

RESOURCE  ROU-UP  DTO 

13 

2A0 

18720 

130 

RESOURCE  TRANSMIT  DTO 

13 

2A0 

18720 

13P 

AIRCREWS  MR 

A 

180 

A320 

I3Q 

AIRCRAPT  MC 

A 

180 

A320 

53A 

BASE  NAME 

15 

100 

9000 

53B 

BASE  TYPE 

3 

5 

90 

53c 

BASE  GEOGRAPHIC  AREA 

21 

5 

630 

53D 

BASE  OPERATIONAL  STATUS 

3 

5 

90 

53E 

BASE  NBC  STATUS 

3 

5 

90 

53P 

BASE  STIC 

11 

100 

6600 

530 

BASE  STATUS  RBURKS 

IAO 

100 

8AOOO 

53H 

BASE  STATUS  AS  OP  DTG 

10 

100 

6000 

53J 

BASE  SHORT  NAME 

A 

100 

2A00 

53K 

BASE  COUNTRY  NAME 

15 

20 

1800 

5AA 

ORDBI  IDENIIPIBR 

23 

1 

138 

SAC 

ORDER  TYPE 

7 

1 

A2 

SAD 

ORDER  ID  NUMBER 

A 

1 

2A 

SAB 

ORDER  DATE 

7 

1 

A2 

SAG 

ORDER  CHANGE  NUMBER 

A 

1 

2A 

5AK 

ORDER  CUSSIPICATION 

21 

t 

126 

56A 

TASKED  UNIT  NAME 

10 

80 

A  800 

56E 

BASE  NAME  -  UNIT  BMPLOYNENT  LOCATION 

15 

80 

7200 

56P 

UNIT  EMPlOIMBin  DAY 

5 

80 

2A00 

560 

T  UNIT  DAILY  SORTIE  TASK 

A 

A800 

115200 

56H 

T  UNIT  DAILY  INTEGRATED  SORTIE  CAPABILITY 

A 

A800 

115200 

59B 

UNIT  NAME 

7 

80 

3360 

59c 

UNIT  TURN  TIME  POR  ORDER 

A 

1600 

38A00 

59D 

PERIOD  START  MY  POR  UNIT'S  PIECE  OP  ORDER 

A 

20 

A80 

59E 

PERIOD  END  MI  POR  UNIT'S  PIECE  OP  ORDER 

A 

20 

A80 

59P 

UNIT  MAINT  ATTRIT  RATE  POR  ORDER 

A 

1600 

38A00 

59H 

UNIT  AIRCRAPT  REPAIR  RATE  POR  ORDER 

A 

1600 

38AOO 

591 

UNIT  MIN  TIME  BETWEEN  TAKBOPPS 

A 

1600 

38AOO 

59J 

UNIT  COMBAT  ATTRIT  RATE  POR  ORDER 

A 

3200 

76800 

71A 

ORDER  IDENTIPIER 

23 

1 

138 

7  IB 

TASK  PmOD  START  MY 

A 

20 

A80 

7.3 

TASK  PERIOD  END  MY 

A 

20 

A80 

7ID 

RESOURCE  TYPE  REQUIRED  POR  TOTAL  ORDER 

20 

A2 

50A0 

71B 

RESOURCE  QUANriTY  REQUIRED  POR  TOTAL  ORDER 

A 

201600 

A838A00 

73A 

UNIT  NAME  -  POR  TASKED  UNIT 

10 

80 

4800 

B-14 


V 


33861 


LOGISTICS  READINESS  CENTER  (LRC)  (Continued) 


APPEARANCE 

NUHBER 

APPEARANCE  NAME 

SIZE 

QUANTITY 

TOTAL 

SIZE 

73C 

RESOURCE  TYPE  SUPPORTINO  UNIT  TASK 

A 

42 

1008 

7  3D 

T  UNIT  DAILY  RESOURCE  SORTIE  CAPABILITY 

4 

201600 

4838400 

73? 

T  UNIT  DAILY  RESOURCE  QUANTITY  CAPABLE 

4 

201600 

4838400 

73L 

UNIT  RESOURCE  AHOUNT  TASKED 

4 

201600 

4838400 

96B 

RESOURCE  NAME 

23 

39 

5382 

96C 

RESOURCE  STATUS 

3 

3900 

70200 

96D 

RESOURCE  BTIC 

11 

3900 

257400 

TOTAL  DATA  SIZE  =  20598252 


TOTAL  OPERATIONAL  DATABASE  SIZE  =  A77879A4 


33861  B-15 


PERSONAL  READINESS  CENTER  (PRC) 


APPBARAMCK  TOTAL 


NUMBER 

APPEARANCE  NAME 

SIZE 

QUANTITY 

SIZE 

1C 

UNIT  MISSION 

3 

15 

270 

IP 

UNIT  SHORT  NAME 

8 

100 

4800 

53A 

BASE  NAME 

15 

100 

9000 

53B 

BASE  TtPE 

3 

5 

90 

53C 

BASE  OEOGRAPHIC  AREA 

21 

5 

630 

53D 

BASE  OPERATIONAL  STATUS 

3 

100 

1800 

53B 

BASE  NBC  STATUS 

3 

100 

1800 

53P 

BASE  ETIC 

11 

100 

6600 

530 

BASE  STATUS  RBURKS 

uo 

100 

84000 

53H 

BASE  STATUS  AS  OP  OTO 

10 

100 

6000 

53IC 

BASE  COUNTRY  NAME 

15 

20 

1800 

53K 

BASE  COUNTRY  NAME 

15 

20 

1800 

96B 

RESOURCE  NAME 

23 

30 

4140 

96C 

RESOURCE  STATUS 

3 

3900 

70200 

TOTAL  DATA 

SIZE  I 

192930 

TOTAL  OPERATIONAL  DATABASE 

SIZE  : 

638598 

I 


REPORTS  CELL 


APPEARANCE 

NUHBS 


appearance  name 


SIZE  QOAWriTY 


UNIT  MISSION 
UNIT  SHORT  NAME 
AIRCRAPT  HIS 
base  name 

BASE  TYPE 

base  seographic  area 

BASE  OPERATIONAL  STATUS 
BASE  NBC  STATUS 
BASE  ETIC 

BASE  STATUS  RBURKS 
BASE  STATUS  AS  OP  BTO 
BASE  SHORT  NAME 
BASE  COUNTRY  NAME 
RESOURCE  NAME 
RESOURCE  STATUS 
RESOURCE  STIC 


3 

15 

270 

8 

100 

4800 

7 

100 

4200 

15 

100 

9000 

3 

5 

90 

21 

5 

630 

3 

5 

90 

3 

5 

90 

11 

100 

6600 

UO 

100 

84000 

10 

100 

6000 

A 

100 

2400 

15 

20 

1800 

23 

39 

5382 

3 

3900 

70200 

11 

3900 

257400 

BATA 

CO 

00 

II 

452952 

ABASE  SIZE  : 

1068966 

OPERATIONS  PLANS  (XPX) 


APPBARAHCB  ‘  TOTAL 


NUMBER 

APPEARANCE  NAME 

SIZE 

QUANTITY 

SIZE 

1C 

UNIT  MISSION 

3 

15 

270 

IB 

UNIT  OPERATIONS  ISBNTIPIER 

23 

1 

138 

4A 

SOLURS  TO  REASINESS  ISBNTIPIER 

23 

1 

138 

<B 

ORSBR  ISBWriPIER 

23 

1 

138 

AC 

RESOURCE  PRICE  ISEOTIPIER 

23 

1 

138 

AS 

SOLURS  TO  REASINESS  RB1ARKS 

AO 

1 

240 

5A 

RESOURCE  TYPE 

20 

42 

5040 

3A 

RESOURCE  TYPE  NBESES  POR  A  TASK 

23 

11 

1518 

SB 

TASK  TYPE  SET  ISBITriPIER 

23 

1 

138 

as 

RESOURCE  PRIORITY 

A 

7 

168 

SB 

STANDARS  QUANTITY  OP  RESOURCE  REQUIRES 

4 

1100 

26400 

9B 

TASK  PRIORITY 

A 

8000 

192000 

9B 

TASK  PERIOD  PRCH  DAY 

A 

20 

480 

9P 

TASK  PERIOD  TO  DAY 

A 

20 

480 

11A 

AIRCRAFT  UNIT  NAME 

10 

100 

6000 

11C 

AIRCRAFT  HD8 

7 

50 

2100 

13B 

RESOURCE  DBSIONATOR 

20 

3A 

4080 

13BB 

RESOURCE  UNIT  PRICE 

4 

3336 

80064 

13CC 

RESOURCE  ULURS  REQUIRED 

A 

240 

5760 

13s 

RESOURCE  SET  IDENTIFIER 

23 

1 

138 

13SS 

RESOURCE  DOLURS  SHORT 

A 

240 

5760 

'3U 

RESOURCE  RB1ARKS1 

30 

54 

9720 

20H 

RESOURCE  SUPPLY  IDENTIFIER 

23 

1 

138 

5AA 

ORDER  IDENTIFIER 

23 

1 

138 

5AE 

ORDER  DATE 

7 

1 

42 

5A0 

ORDER  CHANGE  NUMBER 

A 

1 

24 

5AK 

ORSBR  CU3SIFICATI0N 

21 

1 

126 

5AQ 

NUHBB1  OF  DATS  TO  RUN  3GH  MODEL 

A 

10 

240 

5AR 

SORTIE  GENERATION  MODEL  RUN  RBAARKS 

A5 

10 

2700 

56A 

TASKED  UNIT  NAME 

10 

80 

4800 

56S 

UNIT  ORDER  IDENTIFICATION 

23 

80 

11040 

S6E 

BASE  NAME  -  UNIT  BIPLOYMENT  LOCATION 

15 

80 

7200 

56P 

UNIT  aiPLOYMENT  DAY 

5 

80 

2400 

560 

T  UNIT  DAILY  SORTIE  TASK 

A 

4800 

115200 

56H 

T  UNH  DAILY  INTEGRATED  SORTIE  CAPABILITY 

A 

4800 

115200 

56J 

UNIT  PUNNED  SORTIE  DURATION 

A 

4800 

115200 

56K 

UNIT  SHIFT  DURATION 

A 

3200 

76800 

56M 

T  UNIT  DAILY  RESOURCE  QUANTITT  TASKED 

A 

192000 

4608000 

59s 

PnilOD  START  DAT  FOR  UNIT'S  PIECE  OF  ORDER 

A 

20 

480 

59E 

PERIOD  END  DAY  POR  UNIT'S  PIECE  OF  ORDER 

A 

20 

480 

590 

MISSION  TYPE 

5 

15 

450 

59K 

SORTIES  P0  DAT 

A 

8000 

192000 

59L 

MISSION  PRIORITY 

A 

15 

360 

7U 

ORDER  ISBmiFIER 

23 

1 

138 

7tB 

TASK  PERIOD  START  OAT 

A 

20 

480 

71c 

TASK  PERIOD  END  DAT 

A 

20 

480 

71s 

RESOURCE  TYPE  REQUIRED  POR  TOTAL  ORDER 

20 

42 

5040 

71B 

RESOURCE  QUANTITY  REQUIRED  POR  TOTAL  ORDER 

A 

201600 

4838400 

71f 

SORTIE  AIRCRAFT  RATE 

A 

1AA00 

345600 

710 

SORTIE  DURATION 

A 

8000 

192000 

73A 

UNIT  NAME  -  POR  TASKED  UNIT 

10 

80 

4800 

73c 

RESOURCE  TYPE  SUPPORTING  UNIT  TASK 

A 

42 

1008 

soFTei 


33861 


B-18 


0 


OPERATIONS  PLANS  (XPX)  (Continued) 


APPURANCE 

NUMBER 

APPEARANCE  NAME 

SIZE  QUANTITY 

TOTAL 

SIZE 

73D 

T  UNIT  DAILY  RESOURCE  SORTIE  CAPABILITY 

A 

201600 

4838400 

73? 

T~UNn  DAILY  RESOURCE  QUAmiTY  CAPABLE 

4 

201600 

4838400 

73L 

UNIT  RESOURCE  AMOUNT  TASKED 

4 

201600 

4838400 

7AB 

RESOURCE  TYPE  IN  UNIT'S  TASKING  PIECE 

20 

3900 

468000 

89N 

PLY  DAY  START 

5 

1600 

48000 

890 

SHIPT  PERCENT  POHMED  AIRCREW 

4 

3200 

76800 

89P 

PLY  DAY  DURATION 

2 

80 

960 

89Q 

SHIPT  START  TIME 

5 

3200 

96000 

TOTAL  DATA 

SIZE  = 

26186832 

TOTAL  OPERATIONAL  DATABASE 

SIZE  = 

63895870 

33861 

i 


SOFfeCH 

B-19 


